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CONFERENCE PUBLICATION 


SECOND NASA TECHNICAL INTERCHANGE MEETING (TIM): ADVANCED 
TECHNOLOGY LIFECYCLE ANALYSIS SYSTEM (ATLAS) 
TECHNOLOGY TOOL BOX (TTB) 


1. INTRODUCTION 


The Advanced Technology Lifecycle Analysis System (ATLAS) project team held a second Technical 
Interchange Meeting (TIM) to collect data for the Technology Tool Box (TTB). ATLAS is a suite of 
analytic tools that enables quick-result engineering trades, technology impact assessments, and evalua- 
tion of alternative design and development approaches for a wide range of space architectures and sys- 
tems. The TTB is a repository of infonnation about diverse technologies; it provides data on current 
and anticipated performance metrics, programmatics, and operations factors for thousands of specific 
technologies. 

Technologists, model developers, and space architecture analysts gathered at the National Space Science 
and Technology Center (NSSTC), July 27 th through July 29 th 2005 in Huntsville, Alabama. Participants 
included members of the ATLAS development team, representatives from the Marshall Space Flight 
Center (MSFC) engineering directorate, regional aerospace contractors, and the NASA Headquarters 
project sponsor. This proceedings document provides background infonnation about the project, 
explains accomplishments toward implementing recommendations from the first TTB TIM, narrates 
the presentations of guest technologists, and describes the consensus of discussions in technical breakout 


sessions. 



2. ATLAS APPLICATIONS 


An important theme throughout the TIM was the need to ensure that ATLAS is as useful as possible 
to NASA in achieving its new architecture and launch goals. NASA’s ambitious near-tenn goals for 
the development and deployment of new flight systems have re-ordered NASA’s priorities and changed 
the set of urgent problems. Sessions throughout the TIM addressed the usefulness of ATLAS in solving 
immediate problems by supporting near-term engineering trades for active programs at NASA field 
centers. There was widespread consensus that ATLAS has significant applications as a collaborative 
engineering tool that directly supports current objectives through trade studies and assessments. 

ATLAS provides the capability to assemble space exploration architectures from a library of Excel- 
based system models that represent systems and infrastructure. System model inputs include selections 
for subsystem or component technologies in the form of a technology profile. Space architects can use 
ATLAS to estimate the impact of technology decisions at the system-of-systems level. System engineers 
can use ATLAS to conduct trade studies of technologies at a system level. Technology portfolio analysts 
can use ATLAS to evaluate technology decisions over the life-cycle of a space exploration architecture. 
A technology database, known as the TTB plays an essential role within ATLAS. System and infra- 
structure model workbooks draw perfonnance and operations data from the TTB to estimate the sizes 
of subsystems and workforces. 

In 2005, the ATLAS project will produce at least 25 Excel-based system models that represent systems 
and infrastructure within three types of space exploration architectures: Apollo, the Phased Capabilities 
and Technologies (PCAT) developed for the Exploration Research and Technology (ESR&T) program, 
and the Point of Departure (PoD) architecture developed by the Exploration Mission Systems Director- 
ate (ESMD) Requirements Division. Just a few examples of system model workbooks in the ATLAS 
library include: launch vehicles, upper stages, landers, rovers, space propellant depots, mission opera- 
tions, and ground infrastructure. To support these models, the ATLAS development team will populate 
the TTB with at least 35 technology records in areas related to: propulsion, materials, power generation, 
energy storage, thermal management, automated rendezvous & docking, environmental control & life 
support systems, and integrated vehicle health management. 
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3. WORKSHOP OBJECTIVES 


The primary technical objective of the TIM was to collect data to enhance the TTB. In addition to this, 
the workshop aimed to advance the TTB through addressing complex technical issues, incorporating 
the priorities and perspectives of the model developers into the data collection process, and to bring 
the team together to identify and maintain focus on high priority areas. Specific objectives for the TIM 
were: 

• Collect state-of-the-art data performance, operations, & programmatic data about existing 
technologies. These included performance metrics for sizing subsystems (e.g., specific energy 
density), operations parameters for sizing workforce and facilities (e.g., mean time between 
failures), and programmatic parameters (e.g., Technology Readiness Level). 

• Identify parametric equations that use the perfonnance and operations metrics for sizing 
subsystems and workforces. 

• Forecast technology performance and operations parameters for the next 30 years. 

• Certify existing data within the TTB through consensus and source citations. 

• Identify technology experts willing to participate in periodic model and data certification 
activities. 
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4. PREPARATION FOR WORKSHOP 


In preparation for the TIM, potential participants received the draft agenda with the background, work- 
shop objectives, and expected products. In the opening plenary session, the ATLAS development team 
introduced the project, explained how to use ATLAS to analyze space exploration architecture portfo- 
lios, described the system models, and demonstrated the database. 

The meeting also built on the first TTB TIM, conducted in November 2004 in Huntsville, Alabama. 
More than 40 participants represented NASA field centers, Concept Exploration and Refinement 
(CE&R) teams, and the Advanced Studies, Concepts and Tools (ASCT) manager from NASA Head- 
quarters. Three break-out sessions discussed the format and content of the TTB, the use of the data and 
models to evaluate space architecture technology portfolios, and the relationship between ATLAS and 
other ASCT projects and activities. The meeting generated recommendations, documented in the confer- 
ence proceedings NASA/CP-2005-213900. Table 1 summarizes key recommendations and explains how 
the development team acted upon them. 


Table 1 Recommendations From November 2004 TTB TIM and ATLAS Team Actions 


Recommendation 

Action Taken 

Certification process for models and data 

Defined process and created model certification form 

Include material options in system models 

Revised models to offer material technology options 

Incorporate integrated vehicle health 
management (IVHM) 

Invited William Kahle , an IVHM expert , to present an overview 
related technologies and associated parameters at this TIM. 

Create Apollo models and collect historical 
data to calibrate ATLAS and serve as a 
baseline comparison system for other 
architectures. 

Models now exist for Lunar Rover Vehicle , Eagle Lander, Crew 
Service Module , and Saturn V. Historical data for subsystem 
and component technologies ready for entry into database. 

Automated notification of TTB updates 

Reusable code is available from the Virtual Research Center 
(VRC) to implement this feature. 

Establish multiple levels of access for the 
web-accessible TTB 

Four access levels now in TTB: (1) view schema but not the 
data, (2) view data but no capability to modify, (3) capability 
to revise data and create records for a holding area, (4) 
administrative capability to move data from holding area to 
baseline database. 
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5. PROCEEDINGS: OVERVIEW 


The TIM was scheduled for two and a half days beginning on Wednesday, July 27 th and concluding 
on Friday, July 29 th . The meeting started with a plenary session in the morning. Presentations in the 
morning plenary sessions provided technical infonnation about ATLAS, the TTB, space exploration 
architecture case studies, system models, and important technologies to be incorporated in future 
versions of the system. The meeting was organized to both share infonnation among all the participants 
while allowing for more focused detailed working sessions. A combination of plenary sessions and 
break out working groups were used to achieve this goal. 

Proceedings are presented here by day, with a section of the report dedicated to each day of the TIM 
and a subsection for each presentation or major topic of group discussion. 


PROCEEDINGS: 

WEDNESDAY 

PROCEEDINGS: 

THURSDAY 

PROCEEDINGS: 

FRIDAY 

Wednesday Plenary 

Thursday Plenary 

Friday Plenary 

> Opening Remarks from 
Headquarters 

> ATLAS Overview 

> Technology Tool Box (TTB) 

> ATLAS Case Studies 

> Integrated Vehicle Health 
Management 

> Thermal Management Subsystem 
Technologies 

> Rendezvous and Docking 
Mechanisms 

> Cryogenic Propellant 
Management , Storage & Transfer 

> Modeling and Tracking 
Technology Performance in 
Autonomous Systems and 
Robotics 

> System Model Presentations 

> Headquarters Commentary 

> Products from the Technology 
Working Group 

> Products from Models and 
Architectures Group 

Closing Discussion and 
Conclusions 


Wednesday Models and 
Architectures Working Group 

> ATLAS Capabilities and Needs 

> Subsystem Interaction 

> Case Study Builder Demonstration 

> Ptolemy II Range Reader and 
Range Writer Objects 

> Expansion of Cost Model 
Capabilities 

Thursday Models and 
Architectures Working Group 

> Resolving the Solver Problem 

> Technology Tool Box (TTB) 
Search Macros 

> Requirements Definition and 
Documentation 

Wednesday Technology Data 
Working Group 

> Data Collection and Vetting 

Thursday Technologies Working 


Process 

Group 


> Data Sets from NGLT and SPST 



> Historical Technology Data from 



Apollo and Skylab 




Figure 1 Proceedings Structure 
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6. PROCEEDINGS: WEDNESDAY 


Wednesday began with a plenary session which introduced the participants to ATLAS and the TTB 
and set the groundwork for the remainder of the TIM. Wednesday afternoon participants broke the group 
into two working groups: the Technology Working Group, made up of technologists and those team 
members working directly on the TTB; and the Models and Architectures Working Group which con- 
tained modelers and team members who discussed issues of importance to the overall ATLAS models. 

6.1 Wednesday Plenary 

Presentations in the Wednesday plenary session provided an introduction to and explained the motiva- 
tion behind ATLAS and provided a context for the afternoon discussions. The morning began with 
opening remarks from the Exploration Systems Research and Technology (ESR&T) program manager, 
John Mankins. Presentations that followed included a project overview by Daniel O’Neil, a system 
demonstration by Clara Welch, a database demonstration by LaMonte Dent, architecture case studies 
by Dr. Harvey Feingold. 

6.1.1 Opening Remarks From Headquarters 

John Mankins provided context for discussions about the role of ATLAS and the TTB and the current 
direction of the Exploration Systems Research and Technology (ESR&T) Program. He emphasized the 
importance of physics based modeling in the decision processes, especially those early in the lifecycle 
of projects. System models use performance parameters from the TTB and generate a system summary 
used by development cost models. Technology performance forecasts in the TTB are coupled with pro- 
grammatic parameters like Technology Readiness Level (TRL) and required funding. This integration 
of technology forecasting and physics based cost estimating provides a powerful tool for R&D planning. 
It structures conversations about technology. For example, a system concept has solar arrays, by pulling 
kilowatt per Kg for competing technologies from the TTB into the model; one has a realistic means 
of comparing the impact of a technology decision. Technologist should appreciate ATLAS as a tool 
for building advocacy. 

John explained consensus based decision support tools such as the Analytical Hierarchy Process (AHP). 
The Requirements Division in the Exploration Systems Mission Directorate (ESMD) applied the Strat- 
egy to Task to Technology (STT) technique, a relentless process that produces an integrated set 
of “Houses of Quality” starting from the strategic things the user wants to accomplish and drilling down 
to the technologies he or she wants to develop and characterize. Consensus based tools serve to organize 
the debate about desirable features or figures of merit that are difficult to quantify within a short period. 
Results from consensus based decision support tools appear quantitative but they are not repeatable. 

If one conducts the exercise with a different group of people, the consensus may be different because 
of the strength of the opinions of the most influential people in that group. 

Illuminating the history of ATLAS and the TTB, John identified the lineage of technology analysis 
tools that laid the groundwork. Back in the 1980’s, the Office of Aeronautics and Space Technology 
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assembled a comprehensive document containing hundreds of space mission opportunities called Space 
Systems Technology Model (SSTM). Actually, the information was not a model because a user could 
not interact with it. It was in the SSTM where Stan Sadin brought the TRL into NASA technology 
assessments. In 1985, CRC Press published R. Michael Hord’s Handbook of NASA Future Missions 
and Payloads that was based on the SSTM. It was a big blue volume of technology descriptions. Essen- 
tially, the TTB is a living version of the SSTM. In the mid 1990’s, a team working with NASA devel- 
oped the Integrated Architecture Analysis Model (IAAM) and SAIC developed the Space Segment 
Model (SSM) to evaluate Space Solar Power (SSP) system concepts. Starting in 2002, a multi-center 
team began defining requirements for the Technology for Human and Robotic Exploration and Devel- 
opment of Space (THREADS) Integrated ANalysis (TITAN) model. In 2003, a team led by Daniel 
O’Neil, produced a prototype, which provided the team with the experience to develop ATLAS. 

John concluded his commentary with his perspective on the changing environment at NASA Head- 
quarters. He explained the processes underway in the Exploration Systems Architecture Study (ESAS), 
also known as the Sixty-Day study will drive many of the changes. The release of the study results 
was delayed due to the Shuttle launch but a few news sources have already published information about 
the proposed architecture. According to those sources, the proposed architecture includes a heavy lifter. 
Initially, the launch vehicle will send the Crew Exploration Vehicle (CEV) to the International Space 
Station (ISS). The schedule is aggressive; instead of a nine year schedule, the CEV will be deployed 
in five years. 

Efforts within the ESR&T and Human Space Research and Technology (HSR&T) programs will be 
deferred in favor of finding money for the near-term objectives. There will be a very significant planned 
reduction in Research and Development (R&D) of advanced technology. Support for tools related to 
technology development investment might be overcome by events. In a restructuring of Headquarters, 
twenty people were reassigned to field centers. There will be significant changes in the ESMD program 
management, as well as sweeping changes in roles and responsibilities at the field centers. There may be 
similarities between the new organizational structure and the NASA of the 1980’s when there were lead 
centers for technologies. John summed up the situation by saying there are dark clouds and lightning 
on the horizon for the ESR&T projects. He asserted that ATLAS and the TTB can help project managers 
in this new environment by providing the capability to compare currently available technologies and 
estimate the impact of those technology decisions at the system-of-systems level. 

6,1.2 ATLAS Overview 

A project overview was presented by Daniel O’Neil and a demonstration of the system was conducted 
by Clara Welch. While demonstrating the system, the two explained the underlying functionality of 
ATLAS how it can be used for architecture assessments as well as other analyses. Analysts can operate 
ATLAS in two ways: a script mode or a menu mode. In the script mode, the ATLAS controller opens 
a space architecture case study workbook and loads input data into several models from a script, collects 
the system model output data, and runs cost models for system development, operations, and lifecycle 
economics. In the single model mode, an analyst opens one model at a time, enters mission and 
configuration parameters, selects technologies, and generates mass and cost reports. When running 
in the single model mode, the ATLAS controller calls the system development cost model but it does 
not call the operations and economics models. A tool-bar in the ATLAS application provides buttons 
for loading case studies or models and s tart buttons to run the models to generate reports. 
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During startup, ATLAS loads a default case study workbook. A case study contains a worksheet named 
Script that lists a series of models and the input data for those models. Other worksheets in a case study 
workbook identify launch vehicles and launch dates for use by the operations, cost, and economics 
models. 

Figure 2 presents the Introduction sheet and the Script sheet of a case study workbook. A diagram on 
the introduction sheet depicts the architecture specified by the script sheet. Rows of the script worksheet 
specify the system model workbooks represented by the icons in the space architecture diagram on the 
introduction sheet. Columns in the Script worksheet identify the input data for those models. Column 
‘C’, of the Script, identifies a “Manifest” column at the top of the worksheet. After running a model, 
the ATLAS controller returns the wet and dry masses of the system to the manifest column specified 
in the script. Input fields in subsequent models can use the data in the manifest fields. With this feature, 
the script serves as a patch-panel for passing the output data from one system model workbook to the 
input data of another system model workbook. 


Example Lunar Scenario #3 “Highly Reusable’ 

Appropriate ATLAS models listed next to each icon 

MOON 



A1 

- 

£ 








A 

B 

Manifest 1 

c 

Manifest 2 

D 

Manifest 3 

E 

Manifest 4 

F 

Manifest 5 

a 

Manifest 6 

H 

Manifest 7 

Manifest 8 

i 


2 

Total Wet 
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Dry 
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Figure 2 Example Space Architecture and Associated Script 
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The demonstration presented the reports generated from the default case study, which involves multiple 
launches for lunar exploration missions. Reports from a case study include a stacked bar-graph of 
subsystem masses for each of the systems specified in the script. Figure 3 presents a few of the charts 
generated by ATLAS. The upper stacked-bar graphs present the system masses and development costs 
for the collection of systems that comprise a space exploration architecture. Subsystems in the mass bar- 
graph are specified by a System Summary worksheet in each of the system model workbooks. These 
two charts are available in both modes. 

A System Summary worksheet has a standardized system breakdown structure. If a system model does 
not include a particular subsystem, the summary simply specifies a zero value for that subsystem. A few 
examples of subsystems in the System Summary include solar power generation, power management 
and distribution, energy storage, structures and pressure vehicles, thermal management, propulsion, crew 
accommodations, communications, command and data handling, and consumables. A System Costs 
stacked-bar graph presents the system development costs for Design Development, Test, and Evaluation 
(DDT&E) and Theoretical First Unit (TFU). 

The lower two charts in Figure 3 depict the life-cycle cost chart and technology portfolio forecasts. 

These two charts are only available in the script mode. An area chart presents the lifecycle costs such 
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as system development, production, and operations. Each system model includes technology options, 
the selected technologies go into a technology portfolio. Through an Integrated Technology Analysis 
Module (ITAM), ATLAS produces a technology portfolio from the technologies selected in each system 
model. The lower right chart in the figure depicts the improvement of a critical perfonnance parameter 
versus Technology TRL. The technology forecast charts present estimated perfonnance data over a 
30 year period along with estimated TRLs for a given level of funding. This data comes from technology 
experts who participate in the TTB TIMs. 

Demonstrating the menu mode involved selecting the Eagle-Lander model via the ATLAS drop-down 
menu, selecting technologies and specifying the payload capacity. Daniel and Clara ran the model twice 
with different input data to demonstrate that the report generator would create a bar-graph with the 
results from each session. This feature provides the capability to conduct trade studies of different 
mission, configuration, and technology parameters for a system concept. 

6.1.3 Technology Tool Box (TTB) 

Following the ATLAS demonstration, Daniel O’Neil and LaMonte Dent demonstrated the web- 
accessible version of the TTB. ATLAS uses an Excel workbook version of the TTB kn own as the 
Working TTB. Subroutines within the ATLAS controller search the Working TTB to find performance 
data for the system models and operations data for the infrastructure models. As a collection of run-time 
look-up tables for system models, the Working TTB is fine. As an application for collecting, searching, 
and reporting data to a community of technologists, system model developers, and project managers, the 
Excel version is not suitable. The web-accessible TTB provides a professionally designed graphical user 
interface (GUI) that presents a Work Breakdown Structure (WBS) for navigating through technologies 
associated with space exploration systems. Figure 4 depicts the web-accessible TTB GUI. 

A tree-view on the left side of the GUI presents the TTB schema or technology WBS. Through this tree- 
view, people can drill-down to a technology record. A location path at the top of the screen describes 
the current location within the database and provides a capability to navigate back up through the tree. 

A Search button above the tree-view provides another approach to finding records. 

Record information in the upper section of the central part of the screen identifies the WBS number, 
the name of the technology, and includes a description field. Below the record information, tabs provide 
access to fields for technology perfonnance, operations, and research and development programmatic 
data. The screen image in Figure 4 presents the technology performance fields. These fields include data 
that describe the perfonnance metrics, the values, a reference, and a status. In the reference field, a tech- 
nologist can cite the source of the performance value for the specific metric. A pull-down menu in the 
status field presents options to specify whether the data value is a place-holder, un-vetted, or vetted data. 
The back-ground color of the fields will change color based on the status. A red background indicates 
low confidence in the metric value, a yellow background indicates some confidence, and a green back- 
ground indicates high confidence in the data. 

A time-frame field in the upper right portion of the GUI identifies a year and buttons to the right and left 
of this field provide the capability to move to another time-frame. Each time-frame represents three 
years into the future; so, time-frame zero is the current year and time-frame 10 is thirty years from now. 
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Figure 4 Web-Accessible TTB Graphical User Interface 


Technologists can forecast the perfonnance, operations, and required funding to support the forecast. 
For some technologies, the performance may be the same over multiple time-frames but the maturity, 
i.e., TRL advances from a four to a six or seven. In other cases, the TRL may be the same but the per- 
formance increases. Check boxes, not depicted in the screen image, provide a capability to enter the 
same data in multiple time-frames. 

Other important features of the web-TTB include individual account controlled access, content man- 
agement, and import and export functions. Each account has an access level. For a minimum access 
account, the GUI will present the WBS tree-view only. Access can be restricted to specific groups or 
users on each category of records or individual records. A content manager places all new or modified 
records in a “waiting for approval” state until reviewed and approved by an administrator. The adminis- 
trator has the capability to incorporate the records into the baseline database. Also, the administrator 
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account has an import function to read data from an Excel workbook and an export function to generate 
a Working TTB file. 

Near term plans for the web-TTB include the creation of a change log that tracks and dates all changes 
and can provide a history of the TTB, a discussion forum that allows for a text-based discussion to be 
attached to records in the TTB, and automated e-mail notifications to the user community about new and 
updated records. If approved for Phase II, the TTB developer will research Application Programming 
Interfaces (API) that provides remote access to TTB data directly from the server. Potential APIs for 
this capability include Simple Object Access Protocol (SOAP) and Remote Method Invocation (RMI), 
which is secured by 128-bit encryption. 

6,1.4 ATLAS Case Studies 

Dr. Harvey Feingold presented an introduction to ATLAS cases studies and an analysis of recent pro- 
gress in this area. The presentation by Dr. Feingold showed that over the past two years, a total of nine 
ATLAS case studies have been developed representing seven different lunar mission architectures. 

In 2004 these architectures ranged from fairly simple Apollo analogies such as Case Study Lunar la 
and Case Study Lunar lb which characterized fully expendable all-up and split (lander is launched 
separately) missions respectively; a highly reusable architecture (Case Study Lunar 3) which featured 
a Low Earth Orbit (LEO) propellant depot and Solar Electric Propulsion (SEP) tugs used to ferry the 
lander to the moon and back for refueling; and finally a complex, fully reusable architecture (Case Study 
Lunar 4) that augmented the SEP tugs and LEO depot with a propellant depot in Low Lunar Orbit 
(LLO) and a Reusable Lunar Lander used to transport the crew to the Lunar surface and back to LEO 
after refueling once in LEO and twice in LLO. 

In 2005, a more accurate representation of the Apollo architecture utilizing models for the Lunar Excur- 
sion Module (LEM) lander and Crew Service Module (CSM) was used to develop an Apollo case study 
that could be used for calibration purposes. Three case studies were eventually developed for the Phased 
Capability Advanced Technology (PCAT) architecture. The first two, Case Study PCAT I and Case 
Study PCAT A, were developed originally to represent, respectively, the PCAT Initial architecture 
which used near-term EELVs to transport cargo crew and propellant, and the evolutionary PCAT 
Advanced architecture which employed SEP tugs and reusable chemical stages to expand the overall 
reusability of the architecture. Those two architectures were eventually supplanted by the current PCAT 
architecture which resembles the earlier PCAT Advanced architecture but with less reusability. Finally, 
Case Study POD was developed on the basis of our best guess of the Point of Departure architecture 
coming out of the ESAS activity. 

All told, the nine case studies required a total of 27 different systems that were derived from 20 different 
Excel-based system models. The model usage for each case study is summarized in Figure 5. In this 
figure, parentheses indicate the case study used a different name for the model. For example, the 
Artemis model was used in the PCAT architecture, but referred to as LM within the ATLAS case study. 
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Figure 5 System Models Used in Case Study Architectures 


Dr. Feingold also presented comparative mass and cost results obtained from the 2005 case studies. 
These results were presented for different time frames to show the impact of advanced technologies. In 
comparing the results in the presentation package, it should be noted that the costs for the Apollo and 
POD architectures do not include the launcher costs whereas the costs for the PCAT architecture does. 

6.2 Wednesday Models and Architectures Working Group 

On Wednesday afternoon, programmers, model developers, and space architects discussed the current 
capabilities and requirements for the ATLAS framework and models in the library during the Models 
and Architectures Working Group. Dr. Harvey Feingold moderated the session and Carissa Christensen 
and Paul Guthrie captured the consensus related to resolving technical issues, techniques for improving 
the models, and impressions of new ATLAS products. 

6.2.1 ATLAS Capabilities and Needs 

Regarding the current state of ATLAS, Dr. Harvey Feingold reported that ATLAS is definitely opera- 
tional and can be used to roughly assess the impact of technology choices on a wide range of different 
systems, missions and campaign architectures in tenns of their mass and cost. Furthermore ATLAS has 
shown that it has the capability to handle mission and campaign scenarios ranging from very simple 
(Apollo) to very complex (PCAT). However, he also pointed out that ATLAS is currently much more 
difficult to use (properly) than it should be. 
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One of the reasons that ATLAS is now so difficult to use is that it desperately needs a Working TTB 
that really works, i.e., one with sufficient technology data covering all timeframes, computed secondary 
metrics, and realistic programmatic information. Other ATLAS needs include: 

• Integration of the Mission and Launch Operations models (and their required data sets) 
into the ATLAS economic models. 

• A comprehensive check on consistency between terms and units use by the ATLAS system 
models and those used in the TTB. 

• Implementation of certification processes for both models and technology data to inspire 
confidence in the results produced by ATLAS. 

• Better, more up-to-date documentation for ATLAS developers, contributors and users 

• An overall shakedown and test of all the ATLAS functions and features to ensure their proper 
operation. 

Dr. Feingold also suggested that in addition to mass and cost, the ATLAS development team should 
begin focusing attention on other performance metrics that are affected by technology choice, such 
as reliability, safety, and many different measures of mission effectiveness (e.g., traverse distance, 
information return, power, etc.). 

The group canvassed many potential enhancements to ATLAS. Many of the changes were ambitious 
and appropriate as part of a longer-term development approach. For example, the group advocated pro- 
viding a broader array of underlying ‘measures of goodness’ encompassing mass, cost, safety, and tech- 
nical performance factors that measure mission outcomes. The group also discussed enabling users to 
define their own novel or innovative elements to mission segment models- for example, using oxygen 
and water tanks as radiation shield. 

The group also converged on a number of relatively near-term changes. First, the group agreed that an 
ATLAS user should be able to define technology capabilities to support what-if analyses. This presents 
something of a challenge, because it raises the question of whether the user should be allowed to change 
the data in the Technology Tool Box, which could create version control problems. The solution the 
group agreed upon was to add a “user-defined technology” capability to the TTB. 

The group agreed to programming improvements. One change was to ensure that a query of the TTB 
that found no data reported as ‘none’ rather than reporting as an error. Another change was to allow 
the case study Script page to pass information other than mass (such as wet mass, dry mass, and volume) 
as well as enabling up to ten user-defined parameters. 

Finally, the group determined that it would be useful to provide more detailed data on mission scenarios 
by incorporating existing PowerPoint descriptions of missions into the sample case folder. This would 
enable users to more easily use the associated artwork as a starting point for creating future case studies, 
as PowerPoint artwork is easier to work with than the embedded Excel artwork. 
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6.2.2 Subsystem Interaction 

Evaluating the system-of-systems level impact of technology decisions at the subsystem or components 
level presents a considerable challenge to developing spreadsheet models. In developing models it is 
extremely important to provide for a means for communication of key parameters between models. 
Changes in one system or subsystem can have a ripple effect throughout the system in which they 
are used in or possibly affect other systems with which they interface throughout an entire architecture. 
Sometimes a very small change in a subsystem can ripple throughout an architecture and result in an 
overall large change in the architecture. Often, this phenomenon is referred to as the “Butterfly Effect”. 

Dr. Edward Lorenz defined the butterfly effect in his 1972 paper, “ Predictability : Does the Flap of 
a Butterfly ’s Wings in Brazil set off a Tornado in Texas? ” at an American Association for the Advance- 
ment of Science meeting. As a developer of meteorological mathematical models, Lorenz learned that 
small changes in one part of a weather system can cause major changes in another part of the system. 
Within the context of ATLAS, the butterfly effect describes the possibility of significantly altering the 
life cycle cost through small changes in technology, mission parameters, or system configurations. 

A change in a system may affect the cost of operations, so the butterfly effect describes small changes 
that indirectly cause large differences in the life cycle cost. 

Like ripples in a pond caused by the plunking of a pebble, a change in one subsystem within a system 
affects the design of other subsystems. Achieving the ripple effect requires a network of equations where 
calculated values from one subsystem spreadsheet are variable inputs for equations on other spread- 
sheets. A ripple effect describes the level interconnectivity among sizing equations in multiple subsys- 
tems. Multiple sources of ripples in a pond cause interference patterns where the effect from one cause 
intersects the effect from another cause. Complex interrelationships can cause unexpected results in 
a spreadsheet model. The more interconnected the sizing equations of the subsystems the greater the 
possibility for non-intuitive changes in the system mass. Discovering non-intuitive relationships among 
system mission, technology, configuration and system mass and performance is one of the goals of 
modeling and simulation. 

To achieve the butterfly effect in a system model, where a small change affects everything, each system 
spreadsheet models must include common technology selections and interdependencies among the sub- 
system sizing parametric equations. These interdependencies will cause a ripple effect when an analyst 
selects a technology or changes a configuration or mission variable. Shrinking avionics provides an 
example of the ripple effect: Though smaller electronic packages reduce the mass and volume of the 
avionics, they increase the amount of heat to be rejected by the system. This increased heat affects the 
Thermal Control System (TCS) and the size of the radiators. Telemetry bandwidth provides another 
example: As the bandwidth and data rates increase, so do the size of the transmitters and receivers. 

These larger communications dishes affect the size of the supporting structure, which increases the 
overall mass of the system, which could require a larger engine or more propellant for the transportation 
system. These changes may be due to operational or physical design changes; however, they may be 
driven by changes in the technologies used in the system or subsystem. Lor this reason it is extremely 
important that the workbook models be designed with this type of interaction in mind. Ligure 6 
Subsystem Interactions That Cause Ripple and Butterfly Effects illustrates the interactions of a 
hypothetical system to demonstrate the potential degree of difficulty involved is assuring the adequate 
data is communicated between models. 
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Figure 6 Subsystem Interactions That Cause Ripple and Butterfly Effects 


One example of this type of analysis was presented during the Kick-Off meeting in April 2005. 

Dr. Harvey Feingold presented the results of some analysis conducted with ATLAS. In his analysis 
of multiple space exploration architectures, Dr. Feingold discovered that adequate development 
and advancement of a solar array technology could save up to $100M over the lifecycle of the space 
architecture; these savings could pay for an additional launch. 

6.2.3 Case Study Builder Demonstration 

Jessica Kessler presented her progress with the case study builder. The purpose of the Case Study 
Builder is to provide the capability to generate case study worksheets graphically, outside of Excel. This 
tool has been written in Java in order to be operational on both Windows and Macintosh operating sys- 
tems. The current version of the Case Study Builder is shown below in Figure 7 and Figure 8. Currently, 
the application is divided between two tabs which allow access to the campaign builder and the mission 
builder interfaces. 

The campaign builder interface (Figure 7) allows the user to arrange missions into a campaign. This 
interface has the ability to import mission data, save and open campaign data files formatted in XML, 
and save and show campaign Option data. The graphics window allows the user to zoom in and out 
of the view, scale the timeline, and redefine the dates on the timeline. The campaign builder also has 
an ‘Export to Excel’ option that allows the user to write to the ‘Mission’ and ‘Options’ sheets of the 
Case Study workbook in Excel. 
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Figure 7 Case Study Builder — Campaign Builder Interface 


The mission builder interface (Figure 8) allows the user to arrange the events that are contained within 
missions, as well as set the models and parameters of the events. This interface has the ability to save 
and open mission data files formatted in XML, and also allows the user to import system models from 
the ATLAS model library. Events and models are added to the graphical timeline using a drag-and-drop 
operation. 

Near term plans for the Case Study Builder include fine-tuning the existing interfaces to make mission 
and campaign building easier for the user, adding the ability to export data to the ‘Script’ page in the 
Case Study workbook, and creating an interactive version of the campaign builder that interprets the 
“cartoon” version of the campaign. 

6.2.4 Ptolemy II RangeReader and RangeWriter Objects 

Wayne Goode presented a review of progress on Ptolemy II for use with the discrete events simulator 
as well as future goals of the project. The Discrete Event Simulator version of ATLAS will need to read 
from Excel files to get data from the models. It will also need to write to Excel files to write the results 
of the simulation and possibly to write inputs to the models. The way to add capabilities such as this to 
Ptolemy, the Discrete Event Simulator, is to write custom actors in Java. These custom actors can then 
be used in models in the same way as the built-in actors. Two actors, RangeReader and RangeWriter, 
were written to read to and write from Excel files. 
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Figure 8 Case Study Builder — Mission Builder Interface 


Apache Jakarta POI/HSSF provides a way to read and write Excel files from Java. A Java class, 
ExcellO.java, was created. It uses POI/HSSF to read/write a value from/to a cell range in a specified 
sheet, row and column. RangeReader, which is a “source” actor, reads a value and sends it as a token. 
RangeWriter, which is a “si nk ” actor, writes the value that it receives as a token. These two actors use 
the ExcellO class to read from and write to Excel files. 

The RangeReader (Figure 9) actor has the following inputs: Token (which is ignored), File, Sheet, Row, 
Column, Rows, and Columns. The Token is a port only. The others are ports and parameters. The only 
output is Value, the value read from the spreadsheet. 

The RangeWriter (Figure 10) functions in about the same way as the RangeReader, however, the input 
token is the value to be written and there is no output. 

A simple model for each Actor was created to test the actor. The models read/wrote several values 
to a spreadsheet. The tests showed that the actors operated correctly. 

The ATLAS model could use these actors to build larger composite actors. However, it is more efficient 
to write custom actors that use the ExcellO class, similar to the way the RangeReader and RangeWriter 
classes do. 
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Figure 9 RangeReader Actor in a Ptolemy II Simulation 



Figure 10 RangeWriter Actor in a Ptolemy II Simulation 
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The entire lifecycle will be simulated in Ptolemy as a Discrete Event model. The various phases of the 
lifecycle are actors in the simulation. Each element of the design will go through the model, from phase 
to phase (actor to actor) simulating its lifecycle from technology maturation to launch and operation. See 
Figure 11. 



Figure 11 The Lifecycle Simulator Design 


A Java class will contain all the information needed to simulate an element of the model: name, the cost, 
cost profile and duration for production, etc. This information will be read by the Mission List object 
and a token containing the object with that element’s data will be created and passed through the model. 

A custom actor will be written in Java to represent the phases. Inheritance will be used to add additional 
features to specific phases where needed. 

The “phase” actor in the lifecycle simulator has two basic functions. It takes times and generates cost. 
For each time period in the simulation it must: 

• Determine how much money is used for that time period 

• Decide if an event is finished. If so, 

o Start another of the same event if needed 
o Trigger the next actor (project phase) 

Each actor will send generated costs to the Accumulated Costs actor which will assemble the data 
and write it to an Excel file. This data can then be used by Excel or another application to generate 
the desired charts. 

6.2.5 Expansion of Cost Model Capabilities 

Wayne Johnson led a discussion on the current state of cost estimating tools. He began with a discussion 
of the current acquisition cost model. He explained the WBS, noted those subsystems that were not 
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being utilized (propellants/consumables), and showed how some sections (particularly thermal) need 
to be handled when making analogous system choices. He also pointed out that Apollo era system analo- 
gies were added for additional modeling flexibility. After the acquisition cost model discussion, Wayne 
talked about the status of the operations costs model. He explained how the newly developed mission 
operations cost model was to be integrated into the current operation cost model. In addition, he pointed 
out that there are only a handful of launcher options in the database and besides shuttle analogy, all 
choices are actually closer to pricing option and not cost. This approach was sufficient for initial devel- 
opment. However, as architectures expand in scope (i.e., to accommodate point of departure or 60 Day 
study-type elements) the need to cost launchers (and their variants) increases. 

This led to a discussion of the need for additional launcher cost modeling. Wayne recommended that 
a new launcher cost model be incorporated into the Atlas framework. He demonstrated a prototype 
model that will allow new launchers to be costed at a system or subsystem level. The user will have the 
option of selecting “pre-configured” launchers from a list. The list will include such options as ATLAS, 
Delta, and Shuttle derived (inline and sidemount). Wayne will work in the near future to finish the 
launcher prototype model and incorporate the mission operations model into the operations cost model. 

6.3 Wednesday Technology Data Working Group 

The Technology Data Working group gathered on Wednesday afternoon to bring together technologists 
and ATLAS team members to focus on collecting data for the TTB and enhancing the database. 
Wednesday’s breakout session including presentations from Dr. Monica Doyle of SAIC on the data 
collection and vetting process; Jim Thomas of ISSI on their efforts to integrate data from the Next Gen- 
eration Launch Technology and Space Propulsion Synergy Team projects; and Dr. Randy Humphries 
of QTEC on their project to collect technology information from the Apollo and Skylab projects. 

6.3.1 Data Collection and Vetting Process 

Dr. Monica Doyle opened the session with a presentation on the data collection process, and the process 
for vetting technology data inputs for the TTB. The value of ATLAS as a decision support tool lies in 
the accuracy of the data in the TTB. The primary source of data is the community of experts active in 
research and development in a particular area. This data is initially collected during ATLAS Technology 
Interchange Meetings (TIMs) which bring together technologists, modelers and end-users. Follow-up 
interviews will be conducted with technologists to obtain updated information as well as potential 
contacts for further technology data. 

Additional data is collected from reports documenting previous study results. For example, the Revolu- 
tionary Aerospace Systems Concepts (RASC) and the Capability, Requirements, Analyses and Integra- 
tion (CRAI) team reports have provided a considerable amount of data to the TTB. Finally, time frame 
0, or state-of-the-art, data can also be found in published specifications. 

The primary site for data entry is the web-based TTB. Users can apply for an account by visiting 
https://atlas.vrc.nasa.gov/ and selecting “Create Account”. Once their account has been approved, 
technologists can submit new data or data corrections to the TTB for any time frame. Data submitted 
for inclusion in the TTB must adhere to the following requirements: 
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• Metric values are specified in SI units. 

• Metric values must not include contingency or margin. 

• All data submitted must contain a reference. (In order to protect proprietary data, these 
references and the names of data providers will not be visible to everyone.) 

• All records have the same pre-defined Tech R&D metrics. (A data provider cannot add a Tech 
R&D metric.) 

• All records have pre-defined Operations metrics. (A data provider cannot add an Operations 
metric.) 

• New performance metrics can be added to any technology. 

• Existing technologies can be modified or updated. 

• Data can be submitted for any time frame. 

Once the data is submitted to the TTB, it must be approved by the TTB administrator before it will be 
available to the modelers. The data in the TTB is color-coded to represent its level of maturity. These 
color codes are described as follows: 

• Green: data that has been validated or certified. 

• Yellow: data has some legacy either from comparison with (very) similar technologies, 
preliminary studies or consensus at TTB workshops. 

• Red: This data is usually inserted to eliminate “TBD” in order to test ATLAS models. 

Interactive TIMs provide a forum for discussing and vetting this data in order to raise the maturity level 
from red to green. Using this data and comparing the resulting ATLAS output with results from previous 
studies or actual missions provides insight into data validity. A formal process for certifying the data 
is outlined in Ligure 12. 

6.3.2 Data Sets From NGLT and SPST 

Jim Thomas from International Space Systems, Inc. (ISSI) presented a summary of their ongoing 
research project for the TTB. The ISSI team conducted engineering analysis of technologies applicable 
to Earth-to-orbit, in-space, and lunar/Mars vehicle and propulsion systems. 

The ISSI effort focused on TTB work breakdown structure (WBS) element 2.6 Space Transportation 
and sub-elements 2.6.2. Vehicle Airframe, to identify technologies for structures and materials for 
2.6.2. 1 Primary Vehicle Structures, 2. 6.2. 2 Pressurized Structures and 2. 6. 2. 3 Secondary Structures 
and Appendages for earth-to-orbit vehicle systems. 

The TTB WBS is a generic non-configuration oriented WBS. The Next Generation Launch 
Technologies (NGLT) System Breakdown Structure (SBS) is a configuration oriented SBS that is used 
to identify and track the various major components and systems during a study. A hardware program 
converts the configuration oriented SBS to a configuration oriented WBS to identify and track each 
major component, system and subsystem for the design, development, test and evaluation (DDT&E) 
program. In order to identify technology areas applicable to the TTB WBS elements, ISSI laid out the 
NGLT SBS elements for comparison to the TTB WBS elements. However, due to the significant 
differences between the two matrices they were not directly comparable. In order to compare the 


22 



Data Certification 
Facilitator & 
Database Developer 


NASA & 
Contractor 
Technologists 




Implement 
Web accessible 
TTB 


Revise 


Develop 
Technology 
Description Form 


X 


Conduct 
Interviews with 
NASA & 
Contractor 
Technologists 


Fill out Technology 
Data form in Excel 
or via Web with 
performance, 
operations, & 
programmatic 
^ parameters. 


Identify sources for 
current data and 
explain rationale 
for forecasted data. 


Clarify 


«y>-f 


r 


j 


Check data forms 
for completeness 
& request additional 
information 


ie> 


Yes 


|~H Enle L 




NASA & 

Contractor Subject 
Matter Experts 


Review TTB data 
records via Web 
or Excel workbook. 


Check data values, 
sources, assumptions, 
and compare with 
other values & 


Identify issues or 
discrepancies and 
request clarification 
^ if necessary. j 



Fill out System 
Section of data 
certification form. 


Participate in 
TTB Workshop 


ATLAS 

Principle 

Investigator 


' Work with ATLAS ^ 
model developers to 
map technology data 


Technology Tool 
Box (TTB) 
Integrator 


X 


Invite a group of 
technologists & 
model developers 
^to a TTB Workshop.^ 

'Resolve issues & ' 
facilitate consensus 
on data veracity at 
v Workshop 


Work with verification 
facilitator to publish 
proceedings 


f \ 

Incorporate 
data into 
official TTB. 


Document 
certification status 
and caveats. 

Request 
clarification if 
necessary. J 



Publish current 
version of TTB. 


Figure 12 Data Certification Overview 


technology areas in the NGLT arch a conceptual study to applicable technology areas in the TTB WBS, 
ISSI used its ValuStream risk assessment process to establish a dual-matrix WBS that has turned out to 
be a very useful tool in our comparison of technology areas applicable to the TTB WBS and the devel- 
opment of technologies. The dual-matrix WBS provided ISSI with the tool to lay-out the NGLT launch 
vehicle subsystem SBS configuration oriented and the non-configuration oriented TTB WBS side-by- 
side for a direct comparison of the two with the technology areas ISSI evaluated for the development 
of technologies applicable to the TTB WBS. 

When ISSI laid out the NGLT SBS for comparison to the TTB WBS, it became evident that there were 
technology areas associated with structures and materials that would be applicable to a booster-stage 
and upper-stage elements. The dual-matrix comparison of the technology areas also provided ISSI with 
insight into other NGLT SBS launch vehicle elements associated with vehicle subsystems, e.g. mechani- 
cal, electrical and thermal; and vehicle facilities, e.g. launch infrastructure, manufacturing, and opera- 
tions. ATLAS contains similar WBS elements but not to the detail of the NGLT SBS. These areas will 
be evaluated during the next several months to determine if they contain technologies applicable to the 
TTB WBS and which can be used to populate the ATLAS TTB database. 

Through the middle of July, ISSI reviewed 23 1 technology areas and determined 115 structural and 
material technologies were applicable to the TTB WBS booster-stage launch vehicle elements. The 
115 technologies identified for the booster-stage element were entered in the ISSI interim ATLAS TTB 
form to support the entry of the data in the ATLAS TTB database and provided to the Tauri group. 

In addition to reviewing the technical data to develop the technologies, ISSI established a methodology 
and developed a review process of the structural and material technologies for the booster-stage element 
permitting ISSI to establish operational difficulty factors (ODFs) metric values from 0.1 to 10 and 
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technology readiness levels (TRL) values from 1 to 9 for each structural and material technology 
identified. 

ISSI also supported Russ Rhodes of KSC and the SPST sub-team’s view, development and reporting 
of operational technologies for both liquid and solid chemical propulsion systems. The review evaluated 
9 earth-to-orbit and 7 in-space rocket engines and identified 28 operational requirements that established 
metric values for operational difficulty factors, operational reliability factors and operational 
environment ratings. 

The technology review process developed a methodology that established a structured and documented 
engineering process that is defendable and repeatable, and will produce a technology database based 
on NASA’s and the aerospace industry’s historical database. The ValuStream process provides an addi- 
tional structured process that uses the dual-matrix WBS to identify, compare, record, and track the 
technologies and the derived metric values. 

ISSI has spent much time reviewing the internet and visiting a college library to research the aerospace 
and aircraft material publications and handbooks to locate material properties that are not proprietary, 
ACI or ITAR controlled data. All of the data used by ISSI to populate the ATLAS TTB database is in 
the public domain. 

6.3.3 Historical Technology Data From Apollo and Skylab 

Dr. Randy Humphries presented an overview of the research underway by QTEC to capture Apollo 
and Skylab technology data for inclusion in the TTB. The QTEC team identified Apollo and Skylab 
subsystem technologies, and developed data sets based on these two NASA flight vehicle systems. 

These data sets, at a minimum, included resources (especially weights), performance parameters, 
and other pertinent operating conditions, which would facilitate technology state identification and later 
parameterization. Identification of the references for data sources was also an important feature of the 
task. The object was for ATLAS personnel to use the compiled data to validate the model and use the 
results as the basis for comparisons. As an additional product, QTEC supplied an SBS to use as the basis 
for construction of the tabular documents. 

The approach for this effort was to use QTEC subject matter experts (SMEs) to produce a Technology 
Table data set to identify technology states and indicate where the data sources are located. From this, 
the derived objective was to collect detailed data that would allow complete definition down to the 
assembly or sub-assembly level (and in some cases, component level). 

At the beginning of the task, SMEs conducted a literature survey and, based on a cursory review, 
a streamlined reference set was selected. In parallel, the SMEs identified tabular data for pertinent 
assembly and subassembly. The basis of the tabular fonnat was the structure of the SBS tree and 
the content of the Technology Tool Box, provided by the customer. The data gathering for the tables 
occurred in three overlapping cycles (roughly bi-monthly for the 6-month period this effort spanned 
(i.e. Oct 2004 thru March 2005.) 

The primary data produced was an Excel Technology Table with tabs representing all significant 
assemblies and subassemblies included in this table set, addressing both the Skylab and the Apollo 
vehicles. Not all tabs (assemblies and subassemblies) were completed but the preponderance was 
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addressed. The generated data far exceeded the minimum goals stated at the outset. In addition, 
a valuable SBS tree was detailed. 

Consistent with the primary desire to gather data, in lieu of attendant management or integration, most 
of the effort was expended in raw data tabulation. SMEs had the latitude to decide individual subsystem 
details sufficient to define the technology state of their assigned subsystem. Even though some data 
scatter occurred, consistency and unifonnity of this data was reasonable. 

Good subsystem definition and depth were achieved for Primary Power, Main Propulsion, ECLSS, Crew 
Accommodations, Consumables, Propulsion, Mechanisms, Reaction Control System (RCS), Rocket 
Motors, Passive Thermal, Thermal Protection Systems (TPS) and Thermal Management. Of these, sig- 
nificant weight data were collected for ECLSS, Main Propulsion, Rocket Motors Primary Power, and 
Crew Accommodations. However, each subsystem’s data depth is different because the data granularity 
depends not only on reporting by the element designers but also the quality of the data sources used 
and the experience and contacts available to the data miners. One hundred twenty-three tables have been 
defined with over 100 populated with some data and 50 to 70 at what is considered a high level of 
completion. 

Figure 13 summarizes the assessment status. Green indicates the subsystem definition was achieved. 
Yellow indicates the need for additional research to define the subsystem adequately. Red indicates the 
subsystem was not adequately defined. “N/A” indicates the subsystem was not addressed in the study. 
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Figure 13 QTEC Technology Tables Completion Estimates 
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7. PROCEEDINGS: THURSDAY 


On Thursday morning, participants reconvened in another plenary session in the morning, and again 
broke into the same working groups in the afternoon. The groups rejoined on Thursday afternoon for 
a brief group discussion, before adjourning for the day. 

7.1 Thursday Plenary 

Thursday morning the participants re-convened to delve into more detail on ATLAS and the TTB. 
Specifically Thursday’s plenary provided technical information for the modelers in the room as well 
as ATLAS model library background for the technologists present. Speakers in the Thursday morning 
plenary session gave catalytic presentations about the state of the art in important key technologies, 
requirements for concept definition, and overviews of existing models in the ATLAS model library. 
Catalytic presentations by the technologists provided the ATLAS modeling team with an insight into 
the types of available technologies and parameters to incorporate into the spreadsheet models. Concept 
developers provided an overview of the types of trade studies that preliminary design teams must per- 
form. System model developers provided the technologists a context for the perfonnance and operations 
data. Bill Kahle presented an overview of Integrated Vehicle Health Management (IVHM). Linda 
Brewster presented a history of docking mechanisms and descriptions of current capabilities. Joe Howell 
presented an overview of a recent cryogenic depot definition study, and Neville Marzwell presented the 
state of the art in robotics and mission related issues in man versus machine decisions. 

7.1.1 Integrated Vehicle Health Management 

A recommendation from the November TTB TIM was to incorporate cross-cutting technologies into 
the systems and operations models within the ATLAS library. Integrated Vehicle Health Management 
(IVHM) is an important cross-cutting technology because it can reduce the size of the “standing army” 
required to monitor the health of space exploration assets. During the plenary session, William Kahle, 
from the Advanced Sensors & Health Management Systems Branch of the Marshall Space Flight Center 
(MSFC) Engineering Directorate, presented an overview of IVHM technologies and associated 
parameters. 

William explained that a number of definitions exist for Integrated System Health Management (ISHM) 
or IVHM. Earlier efforts emphasized vehicle health monitoring technologies. A definition of IVHM 
from the Next Generation Launch Technologies (NGLT) program was: “Integrated Health Management 
is not a single technology, but rather an integrated suite of technologies, which are in turn, integrated 
with other flight and ground operations technologies.” Health management fundamental technologies 
include: hardware technologies, such as sensors, their power, and communications; algorithms and soft- 
ware technologies, such as signal processing, feature extraction, diagnostics and prognostics, model 
based reasoning, and system and mission level state modeling. Figure 14 IVHM Hardware and 
Software Technologies, depicts types of IVHM technologies. 
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Figure 14 IVHM Hardware and Software Technologies 


Another view of IVHM developed by the Defense Advanced Research Projects Agency (DARPA) con- 
sists of layers of application components. Technologies integrated across hardware elements involve 
health assessment, prognostics, decision support, and presentation. Technologies mapped into individual 
hardware elements include condition monitors, signal processors, data acquisition, sensor modules, 
transducers, and infrastructure services. These two views of IVHM architectures can be integrated such 
that a few subsystems have sensors, analog-to-digital (A2D) converters, and nodes that process the data 
to hand off to another subsystem that contains the artificial intelligence for prognostics, diagnostics, and 
recovery. Other subsystems may have this intelligence integrated into assemblies and components. 

Analytical tool development activities at Ames Research Center (ARC) involve the Simple Object 
Access Protocol (SOAP) to acquire input variables and generate reports. William presented lists of the 
input and output variables for these IVHM technology analysis tool development projects. A few of the 
input files include mission simulation profiles, timelines, process dependencies, and fault trees. Data 
for the processes include WBS number, name, duration, process failure rates, labor costs, and fixed 
costs. Outputs from these tools include Mean Time Between Failures (MTBF), Mean Time To Repair 
(MTTR), and Mean Time Between Unscheduled Maintenance (MTBUM). These outputs could become 
values for operations parameters in the TTB. Operations models in the ATLAS library could use these 
parameters to size workforce and facilities for the operations cost models. 

While IVHM rates high among safety and reliability technologies, it also provides opportunities to 
reduce lifecycle costs. William presented the results of a Northrop Grumman study of the cost benefits 
of IVHM based on one vehicle and seven flights per year at 40,000 pounds per mission with a 30 year 
operational service life. By reducing the maintenance and trouble shooting, the study indicated that 
a 610 million dollar investment could save 4.3 billion dollars over 30 years or a 7.0 benefit to cost ratio. 
Investing in IVHM could lead to a 52% reduction in support costs. 
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7.1.2 Thermal Management Subsystem Technologies 



Protecting the people, payloads, propellants, and avionics 
from external and internal heat sources requires integration 
of thermal management technologies. Ramona Cummings, 
a thermal expert, presented an overview of thermal manage- 
ment requirements, design considerations, technologies, 
and spreadsheet modeling techniques. Typically, thermal 
management design requires a knowledge or iterative 
determination of heat rejection and/or generation for mission 
and vehicle processes. Requirements must specify allow 
able temperatures for operations, survival, and safe mode. 
Mission plans generate requirements for tracking (or avoid- 
ance) of Sun, Star, Earth, Moon, or other planets and their 
moons. Subsystem articulations such as servicing and 
payload viewing also generate thermal management 
requirements. 


Figure 15 Mission Environment and Geometry 


Configuration design considerations include detailed geometry, masses, and subsystem connectivity. 

A thermal model ought to determine orbital, albedo, and Earthshine heat loads for the vehicle at nominal 
and articulated configurations. Where appropriate, a thermal model should incorporate insulation effec- 
tiveness, such as Multi Layer Insulation (MLI) e-star or foam core e-star, coolant loop fluid properties, 
mass flow rates, area shapes, line losses, and convection coefficients, latent heats of vaporization and 
sublimation, and ablation temperature regime and latent heat of ablation. 

Spreadsheet analyses typically involve specific geometric shapes, (only a few at any one time) and bulk 
temperature responses (typically detennined per shape). Look Up Tables (LUTs) can be used for view 
factors between specific shapes. Also, averaged or LUTs for orbital, earthshine, and albedo heat rates 
are also used. Single values or LUTs can also be used for surface properties, material thenno-physical 
properties, convection coefficients, ablation properties, coolant loop area shapes, MLI e-stars and foam 
core e-stars. Variables for thermal modeling involve surface properties as function of temperature and 
angle of incidence. These variables include: solar absorptivities, infrared (IR) emissivities, solar and IR 
transmissivities, solar and IR specularities, and refractive indices. Thermo-physical properties, or per- 
formance parameters, of materials include: conductivities (as a function of temperature, pressure, 
and/or constituent lay up orientation), specific heats (as a function of temperature and where appropriate, 
of fusion criteria.), and densities as a function of temperature. 

Thermal analysis spreadsheets can estimate steady state and transient temperatures based on the system 
configuration, mission environment, and material properties. Spreadsheets with driving thermal math 
models (TMM) do have serious limitations. Although TMM entity dimensions can be adjusted from 
the spread sheet interface, re -meshing will not be conducted. This limitation means that entity size and 
aspect ratios could exceed limits affecting accuracy. Additional logic can be added to the spreadsheet 
such that out-of-range requests are rejected. Requested parameters can be illogical. However, more 
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software logic on spreadsheet side can mitigate this. In addition, Ramona suggested a few technology 
specific options for possible incorporation in a system spreadsheet model: 

• Insulation: MLI, foam, advanced Aerogel, or offset honeycomb vacuum insulation 

• Tailoring surface properties: heaters, louvers, or thermo electric coolers 

• Heat pipes: conventional or solid state 

• Open loop flow control: vaporization 

• Refrigeration: Peltier (thermo-electric) or dynamic 

• Radiators: passive or active 

7.1.3 Rendezvous and Docking Mechanisms 

Automated assembly and in-space infrastructure depends on rendezvous and docking mechanisms. 
Linda Brewster presented a historical overview of docking mechanisms and identified a few of the 
subsystem technologies. Her presentation addressed many of the important events related to docking 
mechanisms, including: 

• 1966: Gemini 8 performs the first dock in space 

• 1969: Soyuz 4 performs a manual dock with Soyuz 5 

• 1969: Apollo 9 docks in Earth orbit 

• 1971: Soyuz 1 1 docks to Salyut 1 

• 1973: Skylab’s first dock 

• 1975: Apollo and Soyuz docked 

• 1981: First shuttle launch 

• 1986: MIR begins construction 

• 1990: Hubble Space Telescope begins operation 

• 1998: International Space Station construction begins 

The Gemini program was used to test the planned docking mechanism for the Apollo flights, which 
included a probe and drogue system. The Apollo Docking Mechanism (ADM) consisted of a probe 
housed at the forward end of the command module's apex, inside a docking tunnel, that engaged with 
a dish shaped drogue in the upper docking hatchway of the lunar module. On insertion of the probe into 
the drogue, three capture latches engaged with a hole in the drogue's apex to form a “soft dock”. Firing 
a helium gas charge operated a retraction mechanism of the probe which pulled the two craft together 
with a corresponding ring in the lunar module to form a ‘hard dock’. Crew transfer between the two 
spacecraft was possible through the docking tunnel after removal of the command module’s forward 
hatch, the probe and drogue and the lunar module’s upper hatch. 

The Apollo Soyuz Test Project (ASTP) occurred in 1975, bringing together and docking an Apollo 
and Soyuz spacecraft in Earth orbit. Differences in the Apollo and Soyuz environmental and docking 
mechanisms required the design of a separate docking module that would have to be interspaced 
between the two craft. The Soyuz test project used an androgynous universal docking mechanism 
instead of the standard NASA male mechanism. 
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The Shuttle has demonstrated the ability to perform robotic capture of payloads, such as the Hubble 
Space Telescope, and directly dock with both the Mir and the International Space Station (ISS) using the 
Orbiter Docking System, which uses a modified version of the Russian docking mechanism, the APAS 
(Androgynous Peripheral Attachment System). The APAS system components include an extensible 
docking ring with three inward facing guide pedals with capture latches mounted on the active side. 
These soft capture latches require some force to engage. Also on the active side is a dynamic load 
attenuation that is used to dampen or burn off the post capture energy left in the system. Once captive, 
the ring extends to equalize the ball screw actuators to align the vehicles and then retracts to engage 
structural latches mounted on the APAS base structure. An orbiter can carry several docking mecha- 
nisms. Maintenance on the Hubble Space Telescope has been carried out by attaching Hubble to the 
orbiter using a Flight Support System (FSS) which attaches to a three-point docking mechanism on the 
aft end of the Space Telescope. The FSS platform was adapted from an FSS used during the 1984 Solar 
Maximum repair mission. It has a U-shaped cradle that spans the rear of the cargo bay. A circular 
berthing ring with three latches secures the Telescope to the cradle. The shuttle can also use a robot ann 
to grasp and move payloads. On the tip of the robot arm is an End Effector, a wire-snare device designed 
to fit over a special prong, or grapple fixture, attached to the payload that it handles. The grapple fixture 
can have a foothold attached which allows it to move astronauts in position during Extra -Vehicular 
Activities (EVAs). 

The Space Station’s robot arm is a longer (55’) and more versatile mechanism, capable of more accurate 
placement. It can also move along its mount structure. The Space Station’s Common Berthing Mecha- 
nism (CBM) is used to attach many of the space station’s modules. The CBM system is separated into 
two halves, consisting of active and passive rings. The rings are universal in design so that any passive 
CBM ring can be berthed with any active CBM ring. Once placed in proximity for berthing by an astro- 
naut using a Remote Manipulator System (RMS), the CBM active latches pull the two rings together. 
Next, bolts tighten the berth and compress the seals for an air-tight connection. 

Several mechanisms are currently in the design phase, or undergoing preliminary testing: 

• Orbital Express (light payload) 

• Hubble Rescue Vehicle (3-point latch) 

• Advanced Docking Berthing System (ADBS, formerly LIDS) 

• Alignment, Capture and Mate (ACM) Automated Docking System 

Linda Brewster also answered questions about autonomous rendezvous and docking mechanism 
and approaches and led the group in an animated discussion on this topic. 

7,1.4 Cryogenic Propellant Management, Storage & Transfer 

Today, we have filling stations around the world that provide the capability to extend the range of travel 
for our vehicles. Tomorrow’s space infrastructure ought to include propellant depots for the same 
reason. Joe Howell presented an overview of cryogenic propellant management, storage, and transfer 
technologies. A Cryogenic Propellant Management, Storage & Transfer (CPMST) capability has 
crosscutting applications to virtually all missions requiring in-space operations with pre-positioned 
cryogens. The primary functions include: fluid transfer and long-tenn storage. Combinations of passive 
and active thermal control (refrigeration) ensure long-term cryogenic storage with minimal losses. 
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Preliminary technology experiments have been conducted. Technology development roadmaps and cost 
estimates have been constructed (see CRAI data). 

As a result of the ESR&T Intramural Call for Proposals (ICP), there are three CPMST related projects: 

• Ultra light Zero-Boil-Off Cryogenic Propellant Storage System (JPL) 

• In-Space Cryogenic Propellant Depot (MSFC) 

• Experimentation for the Maturation of Deep Space Cryogenic Refueling (GRC) 

Three dimensional (3D) computer aided design modeling is critical to reducing heat loads into propel- 
lant tanks. Several configurations must be identified and iterated upon. Key attributes for a “good” 
concept: (1) obtain view of deep space, (2) minimize tank view of spacecraft bus, (3) protect tanks 
from solar arrays, and (4) minimize strut heat into Liquid Hydrogen (LH2) tank. To determine final 
configuration and component designs, sensitivity trades must be performed to evaluate system 
performances for varying MLI layers, varying radiator area, and varying cryocooler power levels. 


Total ZBO Related Mass vs Radiator Size 
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Figure 16 System Mass Versus Radiator Effective Area Trade Study 


Some technology development will be addressed though ground testing; however, an orbital flight dem- 
onstrator is recommended to mature the full compliment of cryogenic fluid management and fluid trans- 
fer technologies from a systems integration standpoint. This is a long lead, high cost item. More 
architectural trade studies need to be performed to determine pay-off. The following table presents the 
functional requirements, the state-of-the-art, near-term, and far-term technologies with their TRL. 
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Table 2 Functional Requirements for CPMST Related Technologies 



Figures of Merit 


Required Capability 

Now 

Near Term 

Long Term 

TRL 

Pressure Control 

Propulsive settling 

Controlled within +/ 0.5 
psia in zero-g 

Zero boil-off 

4 

Liquid Acquisition 

Propulsive settling 

98% expulsion 
efficiency w. LOX, CH4, 
& Xenon 

98 % expulsion 
efficiency w. LH2 

3 

Mass gauging 

Propulsive settling 
Bookeeping 

3 -5% accuracy in 
zero-g w.o. settling 

1% accuracy in zero g 

2-4 

Transfer and Distribution 

None being worked 

Not TRL = 6 until flight 
experiment performed 

92-94% o-g transfer 
efficiency 

3 


Competing approaches for in-space propellant transfer include: 

• Zero-g fluid transfer 

• Burning an integrated gaseous Reaction Control System (RCS) thruster(s) before and during 
transfer to settle and provide some milli-g during transfer. 

• Inducing a rotational rate in the vehicle stack (this would require a long acquisition tube running 
from the fluid transfer interface to the far end of each tank) 

• Changing architecture element to handle function by transferring fuel by tank exchange 

Fluid transfer systems can be subdivided into three components, the supply tank, the transfer line, 
and the receiver tank. The supply tank must be emptied of liquid without ingesting vapor and maintain 
a level of pressure sufficient to accomplish the transfer quickly. The transfer line must connect the two 
tanks with a minimum of fluid loss, be conditioned to the required operating parameters, and maintain 
a low pressure drop. Hardware challenges include reliable docking mechanisms; and transfer line 
disconnects capable of sealing against the vacuum of space and low heat leak transfer systems. The 
filling of receiver tanks poses the most technical challenges including the uncertainty of liquid and vapor 
distributions in a ta nk in low gravity, the need to keep maximum tank pressure low to reduce tank mass, 
and for cryogenic liquids the large rate of generation of vapor from the residual energy stored in ta nk 
walls. Presently, the transfer of storable propellants in low-g is done routinely using a flexible bladder 
to separate liquid and vapor. Liquid helium transfer was demonstrated on-orbit but relies on the unique 
properties of superfluid helium to achieve its results. No suitable bladder material for cryogenic 
propellants has ever been found but ground testing at GRC and MSFC has shown that thennodynamic 
techniques such as No- Vent Fill will work. The Vented Tank Resupply Experiment (VTRE) demon- 
strated some alternate transfer approaches using liquid acquisition devices with a storable fluid with 
similar behavior to cryogenic propellants 

One of the technology barriers the CPMST community must overcome is the development of automated 
couplings & disconnects for fluid transfer. Today, commercial ground cryogenic couplings are available 
in sizes as large as 14” in diameter. Several flight storable couplings have been bench tested. Designs 
exist for flight superfluid helium couplings. However, no flight qualified couplings are available. Rec- 
ommendations from the CPMST projects are to contract with current coupling manufacturers to flight 
rate existing design and conduct flight demonstrations in conjunction with other technologies. 
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Liquid acquisition presents another challenge to the CPMST community. Liquid Acquisition Devices 
(LADs) have been used effectively for storable propellants for more than 30 years. Early designs of the 
space shuttle used cryogenic LADs but budget and schedule issues forced the designers to use storable 
propellants (N204 & hydrazine). Environmental concerns led to a desire to move away from current 
(toxic) storable propellants. Currently, NASA’s goals for space exploration require the use of cryogenic 
propellants. Cryogenic data is limited to bench testing with screen samples. No flight experience exists. 
A design database of cryogenic LADs will aid engineers in choosing the correct screen and channel 
geometry. The first step in developing this database is testing screen bubble points for IPA, liquid nitro- 
gen (LN2), and LH2. The next step is to broaden the database for liquid oxygen (LOX) and other fluids. 

Another technology barrier to cross is fluid management: pressure control/long tenn cryo storage. Long 
tenn cryogen storage technology has crosscutting application to virtually all missions requiring in-space 
operations with cryogens. The primary long tenn storage technology elements are insulation, tankage, 
and passive and active cooling. Mitigating the risk of this technology barrier involves producing 
advanced models to design configuration of architecture elements to prevent high tank heating rates 
and minimize expected losses. Developing Zero Boil-Off (ZBO) technologies as proposed in “In Space 
Cryogenic Propellant Depot”, and developing Liquid Hydrogen (LH2) cryocoolers. The following table 
lists the technology requirements, state-of-the-art, near-term, far-tenn performances, and associated 
TRL. 


Table 3 Technology Requirements for Long Term Cryo Storage 



Figures of Merit 

Required Capability 

Now 

FY 2009 

Long Term 

TRL 

Passive Storage 

3%/month 

1 %/month 

0.5%/month 

5 

Active Storage 
(Cryocooler) 

Not SOA 

5-10 yrs LOX storage 

5-10 yrs LH2 
storage 

LOX, CH4, 
Xenon = 4; LH2 
=3 

Pressure Control 

Propulsive 

settling 

Controlled within +/- 0.5 
psia in zero g 

Zero boil-off 

4 


Measuring cryogenic liquid quantity in low-gravity without resorting to propellant settling is one 
of the goals of the CPMST community. Potential applications of this capability include: Shuttle Orbital 
Maneuvering System (OMS)/Reaction Control Systems (RCS) upgrades, cryogenic upper stages for 
expendable launch vehicles, and a next generation launch vehicle. Presently, three concepts under 
parallel development: a compression gauge, a Pressure- Volume-Temperature (PVT), gauge, and an 
optical gauge. Ground tests will demonstrate the proof-of-concept and advance the TRL but all of these 
methods will require a low-g validation. With these technologies, the avionics and ground systems can 
monitor propellant consumption during on-orbit maneuvers and detect leaks. Accurate gauges can 
reduce the propellant margins, which leads to greater payload-to-orbit capability. In-space demonstra- 
tion of these gauges will validate their accuracy claims. 

Systems for cryogen propellants such as liquid hydrogen and liquid oxygen have unique challenges. 
The large scale of the systems for which these propellants are attractive makes any in-ta nk structure 
large and complex. No membrane material that can be used at cryogenic temperatures has been found. 
Elastomeric membranes have poor cycle life in liquid oxygen and hydrogen diffuses through at an 
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unacceptable rate. At these low temperatures metal membranes suffer from poor flexibility and limited 
life due to cracking. This presentation identified a number of technologies to fill the gaps between 
current capabilities and system requirements to fill mission needs. A few of the technologies addressed 
in this presentation were automated cryogenic fluid couplings, transfer line chill, ta nk chill/fill in low 
gravity, cryogenic liquid acquisition in low gravity, alternative options to screen-channel LADs (risk 
reduction), long-life space environment compatible cryogenic insulation and coatings (no thennal 
performance degradation), LH2 flight cryocooler (sufficient scale, high efficiency, long life), and 
various zero-g mass gaging concepts for high accuracy (risk reduction). 

7,1.5 Modeling and Tracking Technology Performance in Autonomous Systems and Robotics 

Dr. Neville Marzwell presented a broad perspective view of autonomous and robotic systems and how 
to model and track their performance. The Autonomous Systems, Robotics, and Computing Systems 
capability roadmap details the infonnation technology and robust hardware and computing technology 
required for NASA spacecraft, robots, and human/robotic teams to explore harsh dynamic environments 
safely and affordably. Associated technologies include autonomous operations, Integrated Systems 
Health Management (ISHM), vehicle control, process control, robotics for solar system exploration, 
robotics for lunar and planetary habitats, robotics for in-space operations, software validation and verifi- 
cation, and avionic systems (incomplete). According to the NASA Advanced Planning and Integration 
Office (APIO), autonomous systems, robotics and computing does not include: supercomputing, data 
archiving and analysis, computer networks and grid computing, Robotic hardware (except as required 
to develop and benchmark software), much of “classic” computer science - compilers, programming 
languages, databases, etc. (except in limited cases as driven by the capabilities above). 

Assessing, modeling, predicting, forecasting technology evolution has challenged system developers, 
researchers, and users for centuries. System developers measure system performance and capabilities 
in terms of functions, operabilities, and “quality of life.” Technologists feel more comfortable with 
focused granularities which they create and understand within their communities... ’’jargon”, e.g., 
resolution, pixel density, I sp , power density per mass or volume, i.e., “physical parameters.” Measuring 
technology correctly becomes too complex and requires experts and specialists, which reduces its value 
as a tool for non-experts, mangers, cost accountants, bean-counters, market developers, and system 
users, which it is supposed to serve in the first place “dollars per capabilities.” 

Exploration is a contact sport. To understand our universe and to search for life, NASA robots and 
spacecraft will be: on and under the surface of Mars, on cliffs and in caves, on asteroids and taking 
samples on comets, on the surface and in the clouds of Venus, under the clouds of Titan, under the ice 
on Europa, and on the moon searching for resources and preparing for a long-term human presence. 
Manned and unmanned missions will be carrying out increasingly challenging tasks far from Earth 
including: habitat construction and long-term habitation, in-space construction of spacecraft and obser- 
vatories, mining and in-situ resource utilization, and deep drilling (lunar, Mars, Europa, etc.), spacecraft 
constellations (interferometry, gravity wave detection, Earth-Sun connection, etc.), scientific laboratory 
tests currently done only on earth, and biological and habitability analysis will augment the missions. 
These missions create pacing NASA challenges in autonomy, robotics, and computing. 

Autonomy, robotics and computing are heavily cross-cutting. Most capabilities are relevant to multiple 
missions and mission classes. For purposes of the roadmap we have listed the first major driver. In many 
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cases these technologies provide control and execution software for hardware developed by other 
capability roadmaps (e.g., drilling, EDL, nuclear reactors, life support, etc.). Conversations with these 
capability roadmap teams have begun and will increase once all teams have full packages. Numerous 
autonomy and robotic capabilities have applications in superficially very different missions (e.g., control 
and execution software shared between rovers, drilling, life support, and interferometry). Such sharing 
can reduce costs, shorten schedules, and reduce risks. This is an important lesson of agency-level 
analysis. Common themes include: 

• Communication latencies create pacing NASA challenges 

• Surface exploration drives autonomy and robotics 

• The other driver is challenging manipulative tasks (construction, drilling, ISRU, constellations, 
science experiments, etc.) 

Visual learning and recognition- Although advances in vision are consistent and of great practical 
use, especially recent object recognition work in the vein of spatially invariant feature detection, break- 
through advances in the areas of visual recognition of human-made and natural objects across extreme 
environmental variation, coupled with learning, enabling fielded humans to explain and identify what 
characteristics to look for and how to categorize what is seen for interpreted perception, would signifi- 
cantly lower the cost and risk associated with robotic inspection and robotic manipulation of structures. 
This capability has the potential to trigger one to rethink the costs of long-duration stays on the moon 
and on Mars. 

Robotic tactile dexterity - Best forecasts will project that robotic dexterity will approach that of 
an EVA-suited human in the near future. If revolutionary advances in robotic tactile, feedback-based 
manipulation enable robots to achieve human naked hand-level dexterity and specific energy with 
human-level tactile feedback, this would completely change the regime of tasks that will be perfonned 
by robots during surface habitation activities. This revolutionary progress, requiring both changes 
in both muscle motor technology and surface sensing technology, would dramatically lower the cost 
of in-space and surface assembly and maintenance activities by more than an order of magnitude. 

All-Planetary Vehicle - Current rovers are limited to exploring small sections of relatively benign 
terrain. However, the most interesting science sites lie in relatively inaccessible and inhospitable 
locations (on the sides of cliffs/craters, up in the mountains, in deep valleys). It would be a breakthrough 
in robotic exploration to have rovers that could go essentially anywhere on a planet that the scientists 
want to go. Besides the obvious need for advances in mobility, this capability would require significant 
advances in perception, planning, control, monitoring, and safeguarding. 

Self-Aware, Self-Correcting Robots - By its very nature, exploration involves dealing with the 
unknown and unexpected. Current robots have limited capabilities for understanding when they are 
outside their limits and, if they are, how to get back to a nominal mode of operations. This is especially 
apparent when things go wrong internal to the robot (such as sensors or actuators malfunctioning). It 
would be a breakthrough in robotic exploration to have a capability that monitors the robot at all times 
for these situations, recovers from (or compensates for) such failures, and learns from past mistakes 
to avoid making them in the future. 
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Crew-Centered and Autonomous Operations - This capability area, shown in Table 4, defines the 
evolution of command and control for both manned and unmanned science and exploration missions. 
This includes: crew-centered planning (activity sequences created by crew rather than ground person- 
nel). Autonomous mission operations involve health and safety monitoring, analysis and anomaly 
recovery, science analysis and optimization, dynamic planning, onboard robust execution, logistics 
and inventory, multi-system coordination and collaboration, human automation interaction, and multi- 
modal interfaces for collaborative execution. 


Table 4 Capability Area for Command of Control of Exploration Missions 


Metric 


Technology / 

SOA 

Target 

Need 

Sub-Capability 

Value 

Date 

Autonomous Navigation 

100m 

1km 

2009 

Aerial Traverse 

1km 

10km 

2015 

Autonomous Navigation 

VL1 

>VL2, cliffs, 
craters 

2015 

Sub-Surface Access 

10’s cms 

10-20 ms 

2013 

Instrument Placement, 


10’s 

2020 

Human-Robot Interaction 


Instrument Placement, 
Field Science 

3-6 

1 

2009 

Field Science 

Dozens 

1-2 

2013 

Field Science 

>100 

<20 

2020 

Multi-modal communication 

80% 

95% 

2020 

Behavior tracking 

70% 

95% 

Human-Robot Field Science 

«1 

3-5 

2020 

Co-located Interaction 


Distance traveled per day 

Difficulty of terrain that is 
accessible 
Drilling depth 
Autonomously controlled 
manipulator degrees of 
freedom 

Command cycles per 
sample acquired 
Command cycles per 
sample processed 
Command cycles to 
survey/characterize site 
Percent of interactions 
interpreted correctly by 
robot 

# robots supervised per 
human 


Operation of crewed missions (Station and Shuttle) is presently a manually intensive process: Station 
flight controllers uplink -500,000 individual commands per year to fly and maintain the craft. A team 
of 50 Station mission planners manually develops a timeline for each crew member, which takes 
2 weeks for each day’s activities. Safety and feasibility constraint checking is not automated, but 
is handled through the knowledge of these experts. The Russians (who do not have constant communi- 
cation via TDRSS as we do) upload some automated procedures. Operation of unmanned vehicles 
is done via ground based sequence generation with some low level task automation and automated 
constraint checking; onboard automated safety procedures are routinely implemented. 

Robotics for In-Space Operations - This capability area, shown in Table 5 defines the robotic systems 
needed for assembly, inspection and maintenance, and human-robot interaction in space. This capability 
includes: 

• Assembly - mass manipulation (large, medium, small, fragile), preparation (unpack, identify, 
order ...), connecting (align, mate, verify), self assembly (deployment, docking, etc...) 

• Inspection - structural (mechanical damage, air leaks, deterioration), access ( under thennal 
blankets, delicate surfaces, confined space locations), component/system failure detection 
(fault detection, non-destructive evaluation) 
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• Maintenance - mass manipulation (medium, small), locomotion (moving to points along fragile 
structures), staging, (protection removal, temporary stowage, connector removal, etc...), human 
rated interface manipulation (crew and robots use same interface to manipulate objects), 
dexterous manipulation 

• Human-robot interaction - multi-agent teams (assistants, surrogates), intent communication 
(feedback, task verification, ...), and time delay compensation 


Table 5 Capability Area of Robotic Systems Needed for Space Activities 


Metric 

Technology / 
Sub-Capability 

SOA 

Target 
Value 
Figure of 
Merit 

Need Date 

# human interventions per task 

Site development & 
maintenance 

> 10 

<3 

2012 

Structural connections per hour 

Site development 

< 10 

> 30 

2015 

Average distance navigated per 
human intervention 

Field logistics and 
operations support 

<100m 

1000m+ 

2020 

Proportion of navigation goals 
achieved 

Field logistics and 
operations support 

96% (MER) 

99% 

2020 

% reduction of human cognitive load 

Fluman-robot interaction 

« 10% 

25% 

2008 (OASIS) 

Maximum parallel human-robot 
supervisions 

Human-robot interaction 

~ 1 

3+ 

2020 (Mars) 

Cubic meters excavation per hour 

Robotics for ISRU 

? 

? 

2015 


Autonomous Systems 


3 
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Figure 17 Roadmap for Increased Autonomy 
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7.1.6 System Model Presentations 


After the technologists and concept developers explained the history, state-of-the art, and future fore- 
casts for important technologies, the ATLAS modeling team presented an overview of the spreadsheet 
system models in the library. Dave Young, from Georgia Institute of Technology, presented an overview 
of the transportation models and explained their model development process. Craig Schafer, from Sci- 
ence Applications International Corporation (SAIC), presented an overview of the Capsule model. Don 
Perkinson, from Jacobs Sverdrup, presented the Low Earth Orbit (LEO) and Lunar Orbit (LO) 
propellant depot models. 

David Young presented an overview of the transportation models developed by the Space Systems 
Design Laboratory at the Georgia Institute of Technology. The Georgia Tech models fall into three 
different transportation categories; earth-to-orbit transportations systems, the in-space transportation 
systems, and the excursion transportation systems. The transportation models are derived from individ- 
ual design activities involving integrated product teams. These models are physics based and derived 
from single point designs using NASA standard conceptual design tools. These single point designs 
are then adapted to be parametric and incorporate the standard ATLAS model template. When the 
models are created the IPT explores a selection of technologies that could affect the model. The team 
then selects the top technologies that affect the model and these technologies are incorporated into the 
ATLAS model. The models are then verified by the IPT at different historical design points. Once these 
models are verified they are sent to the ATLAS integration team to be incorporated into the newest 
version of ATLAS. 

Before the TIM, Georgia Tech delivered 18 transportation models to the ATLAS Integration Team. 
These models are parametric, and depend on design decisions (such as time on surface, number of crew, 
etc.) as well as technology choices (such as structure type and engine performance). Some models such 
as Rapid Transfer Module (RTM) and Propellant Re-supply Module (PRM) were created for a particular 
lunar campaign, while most are general enough to be used for any campaign. A summary of each of the 
inputs and outputs to the transportation models is included in the Model Compendium. 

Craig Shafer presented an overview of the Capsule model. Capsule is a multi-subsystem, physics-based 
analytical model for simulating manned spacecraft. It is derived from the Mass Analysis System Sizer 
(MASS) model developed by D. Fletcher (NASA/JSC). It has been altered to simulate capsule-like 
spacecraft (as opposed to lifting bodies or shuttle-like aerodynamics) and to communicate with the rest 
of ATLAS. Inputs are received from the ALTAS user through the User Choices Sys and User Choices 
Tech selections. Capsule interrogates the Technology Tool Box (TTB) for the current information on 
technology selections. The output masses are reported in the System Summary worksheet. The Configu- 
ration worksheet was developed to drastically reduce the number of inputs required from over sixty to 
a more manageable number. The Configuration worksheet holds the pre-selected inputs for a number 
of spacecraft. The following subsystems are modeled: 

• Avionics (communications, computers and displays, guidance, reentry avionics) 

• Crew accommodations (galley, hygiene facilities, crew health systems, housekeeping systems) 

• Structure (physical structure of the vehicle) 

• Attitude control system 
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• Environmental control and life support systems (atmosphere supply & regulation, ventilation 
and thermal conditioning, fire detection, trace contaminant control, water management) 

• Thermal control system (single or dual loop heat exchange system) 

• Power system (primary and secondary) 

• Extra Vehicular Activity (EVA) (space suits, tools, and airlocks) 

• Landing systems (parachutes, parasails, landing gear) 

• Mechanisms (hatches and other mechanisms) 

• Thermal protection system (heat shields) 

All subsystems report mass, and most report volume and power when applicable. Some iteration 
is required, and is accomplished with circular references. Capsule requires over 60 additional inputs, 
which are controlled by the Configuration worksheet. The Configuration worksheet is a lookup table 
of the inputs for several pre-configured vehicles. The outputs are selected by the vehicle selection in the 
User Choices Sys worksheet. There are also additional inputs in the ECLSS, Thermal Protection System, 
and Thermal Control System models that are not currently alterable by the user or addressed with the 
Configuration worksheet. Such a capability may appear in future versions of Capsule as the TTB 
is filled, provided there is interest in the user community. 

It should be noted that the PCAT CLEM’s power is drawn from a companion Mission Module, which 
generates power from solar arrays. The CLEM’s batteries only provide power during reentry. In order 
to properly simulate this, ATLAS must pass the power requirement to the Mission Module model during 
runtime. This is accomplished by providing the power requirement in the Output ICD table in the ICD 
worksheet. It is also understood that Capsule presently overestimates the dry and gross masses of the 
Apollo Command Module by about 23%. This is due to an overestimation of the structural mass (the 
error bars of the structural mass estimation algorithm is +/- 35%), and a lack of historical mass data 
for its various subsystems. These discrepancies will be resolved as better structural mass estimation 
techniques become available. 

An Integrated Products Team was formed at the TTB TIM to aid in improving and further developing 
Capsule. Future work includes: 

• Improve Thermal Control System (TCS) spreadsheet s) by adding a heat pump and the 
capability to change working fluids, number of thermal arrays, thermal array materials, etc. 

• Add regenerative ECLSS systems. 

• Add selectability of TPS materials and improve TPS mass calculation. 

• Add Crew Exploration Vehicle (CEV) vehicle to Configuration Table. 

• Determine what additional variables need to be user-controlled. Find the right balance of user 
inputs. 

• Implement auto-resizing based on size of crew and duration of inhabitation. 

• Perform volume checking and auto-resizing or issue warnings if volume exceeds limit. 

• Radiation shielding 

After Craig Schafer presented, Don Perkinson, from Jacobs Sverdrup, introduced the group to the Low 
Earth Orbit (LEO) and Lunar Orbit (LO) propellant depot models. The lunar orbit depot is based on the 
growth Centaur, modified for long-tenn storage. It is assumed that transfer vehicles will have about the 
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same ratio of hydrogen to oxygen requirements as the Centaur, and will require roughly the same pro- 
pellant load in the early phase of exploration being addressed here. Growth was allowed to three tank 
sets, thus providing propellant capabilities of 20,000 kg, 40,000 kg, and 60,000 kg. While the Centaur 
uses nested tanks, these could be separated, much additional insulation added, and a fill and drain sys- 
tem included. Infonnation was obtained on cryogenic cooler masses, and a generic cryocooler option 
was included that is a function of insulation capability and number of tank sets. A power system is 
included, interfaced to the TTB for both solar array technology and battery technology. No reboost 
system is included since it is assumed to be in a lunar orbit high enough to not require reboost between 
re-supply visits, at which time the re-supply vehicle can perform reboost maneuvers. 

A Low Earth Orbit Depot is also included in ATLAS. This is a more complex model that includes 
an electrolyzer to convert water into cryogenic oxygen and hydrogen for use as propellants. Since 
it is orbiting the Earth, in includes additional logic to handle orbital altitude and inclination, and orbit 
reboost frequency and decay limits. The storage capability is continuously variable over a wide range. 

7,1.7 Headquarters Commentary 

John Mankins provided his perspective on the progress of ATLAS and the TTB. He recommended 
establishing short-duration Integrated Product Teams (IPTs). In this workshop, modelers have been 
in one working group and the technologists in another group. With technologists and model developers 
working together, an IPT can focus on integrating data from the TTB into the models. Presently, 

ATLAS only transfers masses among workbook models. As an area for improvement; the system should 
pass a variety of parameters. In addition to costs, the system should present other campaign-level or 
system-level benefits. Examples of system-level benefits include: improved performance values, dis- 
tance traveled on the lunar surface, or reliability. A technology could reduce cost, even though it does 
not decrease weight. One possible example is a decrease in operations cost resulting from greater com- 
ponent and/or system reliability. ATLAS and the TTB should provide the capability to define a new 
technology so an analyst can see whether the systems or architectures which employ this technology 
are sensitive to a particular parameter. For example, if we could reach the theoretical limit of a tech- 
nology’s performance is reached, would it significantly affect the system or architecture? Additional 
questions that remain include: 

• How is the current TRL reflected in the overall development/maturation cost of a given 
technology? 

• How should learning curves be applied in computing costs? 

John Ma nk ins recommended that the team think methodologically about applying ATLAS to examine 
these issues. 


7.2 Thursday Models and Architectures Working Group 
7.2.1 Resolving the Solver Problem 

The group discussed an on-going challenge in model development - the use of the Excel Solver tool. 
Solver is an Excel optimization tool for complex formulas. Typically, Solver seeks an optimal value 
for a target cell by varying, within constraints, adjustable cells specified by the user. Solver serves 
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an important modeling function, but its implementation has caused problems. For example, it is not 
always reliable in its indication that it has closed on a value; in some cases, additional iterations have 
been required to generate an optimum result, despite a Solver indicator that showed it had converged 
on a value. 

Many of the calculations for which modelers have used Solver can be completed using carefully struc- 
tured circular references. This approach was preferred by much of the group, because the modeler has 
more insight into its implementation and operation. However, Solver does provide a capability for cer- 
tain types of problems (min/max problems with constraints) that are significantly more difficult to 
replace with an alternative implementation. 

The recommendation of the group was that modelers use the circular reference approach where possible. 
The group recommended that modelers rely on Solver in the near term only where necessary to avoid 
significant additional programming. When Solver is used, modelers are to incorporate a dialog box 
to indicate when Solver has not converged. The group expressed a preference to evolve ultimately 
to a hybrid solution employing a combination of the built-in Excel goal seek function and Excel’s VBA 
capabilities for this type of constrained problem solving. 

7.2.2 Technology Tool Box (TTB) Search Macros 

Clara Welch presented to the Models and Architectures Working Group a summary of search functions 
and macros within the TTB. Currently ATLAS retrieves data from the TTB for two purposes. The first 
aim is to populate system model workbooks with technology “performance” parameters used in calcu- 
lating mass. The second aim is to populate the ITAM with “programmatic” metric data for two main 
purposes, 1) calculating the Integrated Technology Index (ITI) associated with the “TechPortfolio” 
of a given scenario (case study), and 2) generating “Technology Forecast” charts which plot perfor- 
mance parameters and TRLs vs. time for technologies associated with a given scenario (case study). 

To retrieve the data from the TTB workbook, three pieces of information are necessary: 

• The worksheet in which the data is stored (there are 80 worksheets in the TTB workbook). 

• The row on which a particular metric is located (there are multiple rows per technology). 

• The column corresponding to the time frame for which the data is requested (there are 12 time 
frames per sheet). 

The current naming convention in the TTB is such that each three digit WBS number (e.g. 2.10.1) is 
assigned its own worksheet. That sheet then contains the technical information for all of the technologies 
grouped under that technology element. An individual technology can be found on a sheet by searching 
for the unique five digit WBS number. The first occurrence of the number will correspond with the first 
line of the technology record. In order for the Excel models to find the exact row of a particular 
technology record, the “metric name” must be matched, and to find the column, the time frame must 
be matched. Currently the use of mnemonics is different depending on whether the models are being 
populated or ITAM is being populated. 

Search macros developed to populate the ITAM use the TablelD and the TechID (including those 
of assumed technologies) to find the WBS number. It is important that the correct TablelD appear 
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in the units column of the model’s UserChoices Tech sheet. If the model is called out in the Script 
for a given case study, this same TablelD must appear in the units column of the case study ICD sheet. 

The search macros used for populating the technology data in the system models depend on entries 
in the TablelD and TechID columns of the model’s WorkArea sheet. These search macros used the 
sLookup WBS function in the SIAMController to map TechIDs to WBS numbers. They then use the 
exact metric name (also in the model’s WorkArea) and the timeframe (carried along in a variable during 
ATLAS execution) to locate the exact row and column within the TTB. 

If a name is entered in the TechID column of the WorkArea, and it isn’t a valid TechID for the TTB, 
it will be assumed to be user defined, and must have entries in a user defined column in the WorkArea, 
otherwise an error will result (and be logged first to the model’s error sheet, and then to the 
SIAM Accumulator Errors sheet during ATLAS execution). 

The testing of retrieval of data from the TTB into the WorkArea sheet can be performed using just 
the SIAM Controller, the model workbook, and the WorkingTTB. The following screen shot shows 
the Capsule model’s WorkArea, Figure 18, with the TablelD and TechID columns, and an example user 
defined technology (AIRLOCK is the TablelD and None is the TechID). 
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Figure 18 Capsule Model’s Work Area 
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The following code snippet shows how the WBS number is found for a given TechID: 

Select Case sTechID 

Case "MachMech": sLookupWBS = "2.1. 1.4.1" 

Case "MachDM": sLookupWBS = "2. 1.1. 4.2" 

Case "CoreDrill": sLookupWBS = "2.1. 2.3.1" 

Case "UltSonicDrill": sLookupWBS = "2. 1.2. 3.2" 

Case "SCMBG sLookup WBS = "2.2. 1.1.1" 

Case "ThinFilm": sLookupWBS = "2.2. 1.1.2" 

Case "SLA": sLookupWBS = "2.2. 1.1. 3" 

Case "AdvHT": sLookupWBS = "2.2. 1.1. 4" 

Case "Rainbow": sLookupWBS = "2.2. 1.2.1" 

Case "QuantDot": sLookupWBS = "2.2.1. 2.2" 

Case "Brayton ": sLookup WBS = "2. 2. 1.4. 1 " 

Case "SNRPS": sLookupWBS = "2.2.2. 1.1" 

Case "TOPAZII": sLookupWBS = "2.2.2. 1.2" 

Case "CAESTank": sLookupWBS = "2.10.2.6.2" 

Case "GESHydro ": sLookup WBS = "2. 10.2.7.1" 

Case Else sLookupWBS = "" 

End Select 

The above code snippet is semi-auto-generated from a TTB by Steve Patrick each time a new TTB is 
released, and can easily be integrated into ATLAS to add, remove or change TechIDs as they are added, 
removed or renamed within the TTB. 

Note that all that is required to find a WBS number for a given technology is the TechID (incidentally, 
the TablelD field is only used as a flag to indicate that the variable is a technology to be retrieved from 
the TTB). One potential improvement to the TTB would be to organize the technologies into sheets 
(with the TablelD mnemonic instead of using the first three WBS numbers as sheet names, and TechIDs 
as row identifiers rather than the full five WBS numbers. Somewhere on each TechID row, the WBS 
number could be recorded for any necessary cross-referencing. This would allow the TTB to function 
independently of the vagaries of the NASA budget WBS. 

7.2.3 Requirements Definition and Documentation 

Charlie Morris concluded Thursday’s Models and Architectures working group by leading a discussion 
on requirements definition and documentation, and what enhancements can be made to the reporting 
for ATLAS. Application of good systems engineering practices calls for an update to the articulation 
of requirements and other key documentation. This is intended to ensure good communication between 
the developers and the customer/user as ATLAS development continues. After review of an expanded 
set of requirements statements, a streamlined, higher-level set is being crafted for approval. The latest 
set of zero-level requirements covers four considerations: 

1 . Performance - “A desk-top-computer-based tool will allow assessment of the impacts of 
technology and architecture for space systems.” (Level- 1 requirements address: interactions 
with other tools, output parameters, run time, model/technology-set compatibility, etc.) 

2. Ease of operations - “Easily available documentation, training, support and operations 
characteristics will make the code easy to use.” 
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3. Confidence of use - “Configuration management, data management and testing will ensure 
a high level of user confidence in results.” 

4. Schedule and budget - “Agreements with the funding sponsor will define both schedule 
and budget.” 

Some discussion addressed achieving greater near-term utility and confidence by: (a) focusing on a lim- 
ited number of model and technology sets; (b) conducting a well coordinated process of certifying, test- 
ing and documenting to form a core of approved models and technology data; then (c) adding new 
model and technology sets to the approved list by giving them the same rigorous treatment. This may 
require a change in programmatic metrics to promote certifying, testing and documenting rather than 
creating a larger number of models and technology sets. This approach should promote more confident 
use of ATLAS by keeping the user clearly aware of factors such as the limits of applicability for a given 
model as well as relative strengths and weaknesses among the models. 

7.3 Thursday Technologies Working Group 

On Thursday, the Technology Working Group reconvened to further discusses enhancements to the TTB 
and data collection strategies. At the beginning of Thursday’s technology working group breakout ses- 
sion, Elaine Gresham from The Tauri Group presented the ongoing data collection process for the TTB. 
The presentation included a summary of previous data collection efforts such as the filtering of RASC 
and CRAI datasets as well as a status of the ongoing effort. The presentation outlined the goals for the 
technology working group to accomplish in the breakout session. Specifically, she discussed how best to 
coordinate the data needed by the modelers with the ongoing data collection effort. Some time was also 
spent addressing questions from the working group about how to utilize the online version of the TTB 
and, an introduction to gaining access was presented by Dr. Monica Doyle. 

After Ms. Gresham’s presentation, the working group split into simultaneous sessions, with one group 
meeting to discuss changes to the TTB and other big-picture technology issues, while smaller splinter 
sessions engaged in tactical discussion between modelers and technology data providers to find the best 
overlap of useful and available data for the TTB. 

During the larger group discussion, Dr. Monica Doyle presented a summary of changes made to the 
TTB as a result of the inputs received during the previous TTB in November of 2004. Each of the items 
from her presentation generated discussion among the group to better understand the subtleties of the 
TTB in its current fonn. Specifically, the group discussed several field and definitional changes in the 
database (e.g. technology R&D maturation paths, goal and threshold values, data maturity ID); changes 
to the way the TTB operates (e.g. data processing in the TTB, the TTB workbook split); and improve- 
ments to the format and user interfaces in the database. 

While this discussion was ongoing, several of the groups providing data to the TTB were able to meet 
with ATLAS modelers to exchange ideas and data. The idea for integrated product teams (IPTs) was 
proposed on Thursday morning by John Mankins, to consist of ATLAS modelers and data providers to 
coordinate data collection priorities and identify model sensitivity areas utilizing TTB data. A prototype 
of the IPT was implemented in the afternoon technology working group break out session. In these 
groups, ATLAS modelers Dave Young and Craig Schafer reviewed the possible sources of data avail- 
able and how this data could fit within their ATLAS models. Each modeler met with: Dr. Randy 
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Humpries from QTEC regarding the potential uses for Apollo and Skylab data; Jim Thomas from ISSI 
on the utilization and provision of structures and propulsion data; Bob Lovell from MSFC to discuss 
structural models and related data; and Robyn Carrasquillo from MSFC regarding the use and provision 
of ECLSS-related data. 

In addition, Tim Sarver Verhey met with Monica Doyle to discuss data Glenn Research Center (GRC) 
is providing to the TTB. This data includes solar power generation and electric propulsion performance 
and development data compiled and provided by the Power and Electric Propulsion Division at NASA 
Glenn Research Center for use in the ATLAS Technology Toolbox. The data were compiled for the 
following technologies: 

• Single Crystal Multi-Band Gap Solar Cell Based Photovoltaic Arrays 

• Thin Film Solar Cells on Flexible Substrates Based Photovoltaic Arrays 

• Stretched Lens Array (concentrator) Photovoltaic Arrays 

• Rainbow Multi-Band Gap Solar Cell-Based Photovoltaic Arrays 

• Quantum Dot-Based Solar Cell-Based Photovoltaic Arrays 

• Solar Dynamic with Brayton conversion Power Generation 

Array Arc Prediction and Mitigation data were also provided. Additionally, the propulsion technologies 
added to the TTB include: 

• Electrostatic Ion Thrusters 

• Hall Effect Thrusters 

• Magnetoplasmadynamic Thrusters 

The data provided covered four time frames: 2005-2006, 2015, and 2025. The intervening time gaps will 
have to be filled in via extrapolation. This data is in addition to some Power Management & Distribution 
data provided last year. Comparable information on energy storage systems will be sought out for 
inclusion into the TTB. 

Thursday’s Technology Working Group session was concluded with a review of the topics discussed 
and the opportunity to share perspectives on priority areas and possible improvements in the TTB 
and the data collection process. 
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8. PROCEEDINGS: FRIDAY 


On Friday the group shared conclusions and recommendations in a joint plenary session before 
adjourning the TIM mid-day. Each of the sessions and the accompanying presentations from the TIM 
are detailed below; in addition. Appendix A contains the detailed TIM agenda. 

8.1 Friday Plenary 

To kick off the Friday plenary, Carissa Christensen gave a brief presentation on a twenty-year NASA 
technology forecast from 1976. The top-level summary highlighted the findings of the NASA reports 
Forecast of Space Technology 1980-2000, released in January 1976 as an element of a NASA planning 
study, “Outlook for Space,” initiated by Administrator James C. Fletcher in 1974. The technology fore- 
cast was conducted by JPL and supported by NASA centers. 

The presentation described selected forecasts for technology in 2000 drawn from the 1976 study. 

The presentation noted that in general, where forecasts were driven by expectations of NASA funding 
and activity, the level of technology advancement had been appreciably overestimated. A telling 
example is ETO launch prices, which the forecast predicted would be about $50/kg (or $23/lb) in 1975 
dollars. That translates to about $80 per lb in today’s dollars. Of course, today’s actual launch prices 
are nowhere near that low, but are about 200 times higher - around $4, 000/lb to LEO. 

On the other hand, where forecasts were driven by expectations of a moderate to significant level 
of commercial demand, forecasts were more accurate or even underestimated the degree of technology 
advancement. A dramatic example is in the area of data storage, where the NASA forecast predicted 
significant advances, anticipating that by 2000, it would be possible to achieve about 125 GB per cubic 
meter for computer memory. A stack of a few laptop hard-drives easily exceeds that capacity, in 
a volume far less than a cubic meter. 

8.1.1 Products From the Technology Working Group 

Friday’s summary presentation of the two days of progress from the Technology Working Group break- 
out session was given by Elaine Gresham. Ms. Gresham summarized the presentations given and major 
topics of discussion in the working group, and explained the conclusions reached and next steps for the 
group. During her presentation the group participated in a discussion about the recommendations from 
the TIM in November, 2004. Although the TTB team had addressed the recommendations from the pre- 
vious TIM in changes to the fonnat and substance of the TTB, there was no formal reporting process 
for tracking those recommendations. It was suggested that for the next working session that it would be 
beneficial to re-visit the recommendations and report on progress made. This suggestion is planned 
for implementation in the next group meeting. 
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8.1.2 Products From Models and Architectures Group 

Dr. Harvey Feingold presented a summary of the activities and products of the Models and Architectures 
Working Group sessions as well as some conclusions from those sessions. Dr. Feingold opened his pres- 
entation with a summary of the current status and future needs of ATLAS, which were discussed 
in detail during Wednesday’s Models and Architectures Working Group. He explained that ATLAS 
is an operation tool that can roughly analyze the impact of technology choices on a variety of systems, 
missions, and architectures in terms of mass and cost. Although ATLAS is flexible to handle simple 
and complex analyses, it will remain difficult to use until some of its needs are addressed. Most impor- 
tantly, ATLAS needs a working TTB with significant technology data, technology forecasts, and 
realistic programmatic information. Other ATLAS short-term needs include a check on consistency 
of terms and units between the TTB and the ATLAS system models; a certification process for models 
and technology data; more documentation for the ATLAS team; and an overall test of ATLAS functions 
and features for operation. Specifically the working group addressed the TTB, model accuracy needs 
and strategies, and improvements and suggestions for model usability. In addition to presentations 
and discussion on ATLAS status and needs, the working group also addressed the future business case 
for the ATLAS models and systems during Wednesday’s session. 

Dr. Feingold followed this with a presentation on Thursday’s progress in the Models and Architectures 
Working Group. He summarized the session that was moderated by Clara Welch and included presenta- 
tions by Don Perkinson, Clara Welch, Harvey Feingold and Charlie Morris, which were summarized 
previously. Specifically Thursday’s major topics of discussion during the working group included 
problems and strategies for Solver; a demo of impairments to and techniques associated with the TTB; 
a discussion of Script Reader and case study development; and documentation for developing ATLAS 
system models with the model developers guide. This presentation led to an additional group discussion 
on the importance of documentation and short and long-term goals for documenting ATLAS programs 
and procedures. 
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9. CLOSING DISCUSSION 


The meeting ended with a group discussion of near-term actions needed to ensure that ATLAS 
is as useful as possible to NASA in achieving its new architecture and launch goals. These new goals 
are embedded within a new NASA context (depicted in Figure 19) that has moved toward engineering- 
oriented, rather than process-oriented, leadership under the new Administrator, Dr. Michael Griffin. Dr. 
Griffin has defined ambitious, near-term goals and has instituted a focused, headquarters-led study 
process to define a new launch vehicle and architecture to meet these goals. Efforts to ensure critical 
path success in launching a new vehicle as early as 2010 appear likely to rely extensively on 
experienced hardware contractors. 

This near-tenn operations focus has re-ordered NASA’s priorities and changed the set of urgent prob- 
lems. ATLAS, in order to be relevant and useful in this new context, must be demonstrably useful in 
solving immediate problems. The primary role of ATLAS will shift from that of a tool to help HQ man- 
agers plan long-term technology investments to that of a tool to support nearer-term engineering trades 
for active programs at the field centers. 

The group agreed that ATLAS has significant applications as a collaborative engineering tool that 
directly supports current objectives through trade studies and assessments. (An example discussed was 
characterizing the new NASA exploration architecture in ATLAS and showing the driving technology 
and cost differences from Apollo missions.) ATLAS should interact with other collaborative engineering 
tools to be fully useful. 

Figure 19 is a chart presented by Carissa Christensen to summarize some of the recent changes 
at NASA. The chart generated discussion and helped focus the ATLAS team towards aligning future 
efforts with NASA’s highest priorities. The group also discussed longer-term future activities, including 
the development of new models, collecting additional data for mature technologies, and developing new 
metrics that extend beyond mass and cost, to explicitly address mission performance. Group members 
commented on the importance of communicating with relevant technologists, engineers, and managers 
(especially the payload community) and urged all participants in the TIM to share their knowledge about 
ATLAS. Several said they intended to present conference papers on aspects of ATLAS. 

The group discussed the TIM format, and how it could be enhanced at future meetings. Suggestions 
were to, at the next TIM, further expand the discussion of progress since the last TIM and provide 
updates on action items. The group also agreed that the ATLAS project should continue to use inte- 
grated product teams, as piloted at this TIM, throughout the project as needed. There was discussion 
of having more focused TIMs, separately addressing the database, the models, or the software. Finally, 
it was agreed that the most efficient schedule for TIMs would be to start at noon on Tuesday and end 
on Thursday afternoon. 
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Figure 19 Recent Changes at NASA 
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10. NEXT STEPS 


The next ATLAS milestone is the project review, scheduled for August, 2005. A draft of this publication 
will be presented at the review, along with a performance scorecard and programmatic metrics. The 
ATLAS development team will also discuss the potential of ATLAS in advancing NASA’s new 
exploration architecture. 

TIM participants were asked for specific recommendations on future actions and activities to ensure that 
the investment NASA has made in ATLAS continues to yield benefits across the agency. Participants 
identified several key applications for ATLAS in the new NASA context, including its value to near- 
term evaluation and assessment of alternatives. For example, ATLAS can aid NASA in evaluating 
system/technology perfonnance and cost claims in contractor proposals. ATLAS also enables quick 
evaluation of the performance impact of using different technologies in proposed payloads and systems 
for both lunar-based and in-space applications (both crewed and robotic missions). During a program’s 
development phase, ATLAS would enable a user to quickly evaluate the effect of various system 
changes, e.g. growth, on a mission or a full campaign. 

ATLAS is also a useful tool for improving communication and consistency among the many organiza- 
tions and individuals that will be involved in design, development, engineering, test, manufacturing, 
launch, and operation of a variety of systems and payloads. ATLAS can be used to ensure top-level 
analyses are drawing on models making the same assumptions, so that alternatives can be meaningfully 
assessed. In addition, the TTB could serve as a stand-alone technology reference for NASA as well as 
all NASA contractors. 

Finally, participants offered process-oriented recommendations, such as an annual technology review, 
and development recommendations, such as increasing the ease of use of ATLAS to ensure the broadest 
range of users. 

Based on the outcome of the ATLAS mid-term review and guidance from NASA leadership, the 
ATLAS development team will tailor its program plan and activities to ensure that ATLAS continues 
to fulfill its potential to be a valuable aid to the NASA community in meeting the exciting and ambitious 
challenges we face. 
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APPENDIX A— AGENDA 


Technology Tool Box (TTB) 
Technical Interchange Meeting (TIM) 
National Space Science and Technology Center (NSSTC) 
July 27 th through July 29 th 2005 
Agenda Outline 


Wednesday, July 27, 2005 Plenary Session, Room 1010, Capacity: 44 people 
Objectives: Provide context for ATLAS project and present a status of the project and tools. 


Topic 

8:00 a.m. Safety and Logistics 

8:15 Opening Remarks 

ESRT Program Overview 
Motivation for ATLAS and the TTB 

8:45 ATLAS and TTB Project Overview 

Project Objectives 
Model and Data Score Card 

9:15 ATLAS Demonstration 

Running a Case Study or Model 
Technology Forecasts from ITAM 

9:45 Coffee Break 

10:00 Technology Tool Box Demonstration (TTB) 

Establishing an account 
Exporting from MySQL to Excel 

10:40 Architecture Case Studies 

Apollo - for calibration 
Phased Capability And Technology (PCAT) 
Point of Departure (PoD) 

11:20 Lunch 

12:40 Working Group Objectives 

Room Locations, Moderators, and Facilitators 
Expected Products for Thursday and Friday 

12:50 Move to Working Group Sessions 


Presenter 
Daniel O’Neil 
John Mankins 


Daniel O’Neil 


Daniel O’Neil 
Clara Welch 


LaMonte Dent 


Dr. Harvey Feingold 
Bob Thompson 


ALL 

Daniel O’Neil 
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Wednesday, July 27, 2005 (Continued) 

Technology Working Group Conference Room 1010, Seating Capacity: 44 people 


Presentation 

12:50 State of the Database 

Current content and level of certification 
Approach to Programmatic Data collection 


Presenter 

Monica Doyle (SAIC) 

Elaine Gresham (Tauri Group) 


1:40 Material and Structures Data 


Jim Thomas (ISSI) 


2:30 Apollo & Skylab Historical Technology Data 


David O’Neil (QTEC) 

Dr. Randy Humphries (QTEC) 


4:00 Plan for entering data into TTB 


ALL 


Models & Architectures Working Group, Conference Room 4068, Seating Capacity: 24 


Discussion Topics Moderator 

12:50 ATLAS Capabilities and Needs Dr. Harvey Feingold (SAIC) 

Models & technologies required for future architectures Bob Thompson (GT) 


1:40 Subsystem Interaction 

Getting the Ripple Effect 

Currently available subsystem sizing equations 


Steve Patrick (Sverdrup) 
Don Perkinson (Sverdrup) 
Craig Schafer (SAIC) 


2:20 

2:40 

3:10 


Case Study Builder Demonstration 


Jessica Kessler (DCI) 


Ptolemy II Excel Interface Demonstration 


Wayne Goode (SAIC) 


Expansion of Cost Model Capabilities Wayne Johnson (SAIC) 

Using the cost model options in System Summary 

What is the full cost of technology? For example, technology integration 


4:50 Adjourn 


Both Groups 
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Technology Tool Box (TTB) 
Technical Interchange Meeting (TIM) 
National Space Science and Technology Center (NSSTC) 
July 27 th through July 29 th 2005 
Agenda Outline 


Thursday, July 28, 2005 

Plenary Session, Conference Room 1010, Capacity: 44 people 

Objectives: Present an overview of technologies and existing ATLAS system models. 


7:45 

Catalytic Presentation 
Breakfast 

Presenters 

ALL 

8:00 

Introduction to plenary presentations 
Technology overview presentations 
System model presentations 

Daniel O’Neil 

8:05 

Integrated Vehicle Health Management (IVHM) 

Bill Kahle 

9:30 

Thermal management subsystem technology 

Ramona Cummings 

8:55 

Historical overview of Docking Mechanisms 

Linda Brewster 

9:30 

Cryogenic Fluid Management, Storage, and Transfer 

Joe Howell 

9:55 

Future Concepts for Robotics 

Dr. Neville Marzwell 

10:20 

10:45 

Transportation models overview 
Capsule models 

Dave Y oung (GT) 

Bob Thompson (GT) 
Craig Schafer (SAIC) 

11:10 

Space Depots 

Don Perkinson 

11:30 

Perspectives on the evolving role of ATLAS & TTB 

John Mankins 

12:00 

Lunch 

ALL 

1:00 

Move to Working Group Sessions 

ALL 

Technology Working Group, Conference Room 1010, Seating Capacity: 44 people 
Objectives: Explain data certification process and describe forecasting methods. 

1:10 

Presentation 

Technology Data Certification Process 
Establishing consensus and citing sources 

Presenter 

Dr. Monica Doyle 

Elaine Gresham 

1:40 

Technology Forecasting 

Carissa Christensen 
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Thursday, July 28, 2005 (Continued) 

Technology Working Group, Conference Room 1010 


Discussion 

2:05 Review of red fields in TTB and technology forecasts for TBDs 
Energy storage technology 
Power generation technology 
Propulsion system 

3:10 Capture consensus on existing data 

3:30 Discuss improvements to database and data collection process 
Adjusting to new work breakdown structures 
Impacts to the database design 

5:00 Adjourn 


Moderator 
Dr. Monica Doyle 
Elaine Gresham 


Elaine Gresham 
Dr. Monica Doyle 

Elaine Gresham 
Dr. Monica Doyle 


Models & Architectures Working Group, Conference Room 4068, Seating Capacity: 24 
Objectives: Discuss issues and potential improvements to the ATLAS software and database. 


Discussion 

1:10 Resolving the Solver Problem 

Creating a macro within the controller to replace Solver 
Creating a utility to seek out Solver on the local computer 
Replacing Solver calls with circular references 

2:00 Technology Tool Box (TTB) Search Macros 
Eliminating the need for the WBS numbers 
Developing an independent interoperable ITAM module 

2:50 Revising the Script Reader to transfer power and other data 
Adding additional rows above the scripts 
Improvements to the case study script 
Requirements for Case Study Builder 

3:40 Model Developer’s Guide (MDG) Improvements 
What do developers need from this guide? 

Supporting documentation requirements 
Model Certification Process 

4:20 Capture consensus recommendations to system and documents 

5:00 Adjourn 


Moderator 
Don Perkinson 


Clara Welch 


Dr. Elarvey Feingold 


Dr. Elarvey Feingold 
Charlie Morris 


Tauri Group 
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Technology Tool Box (TTB) 

Technical Interchange Meeting (TIM) 

National Space Science and Technology Center (NSSTC) 

July 27 th through July 29 th 2005 
Agenda Outline 

Friday, July 29, 2005 

Plenary Session, Conference Room 1010 

7:45 Breakfast 

Presentation or Discussion 

8:00 Products from the Technology Working Group 

Data sets collected before or during the workshop 
Consensus on existing data marked with red fields 
Plans for follow-on data certification activities 

8:50 Products from Models and Architectures Group Dr. Harvey Feingold 

Recommendations for resolving Solver problem 
Recommendations for TTB Search independence from WBS 
Plans for increased interactions among subsystem models 
Plans for follow-on model certification activities 

10:15 General discussion about the workshop and certification process Carissa Christensen 

Capture audience recommendations for workshop improvement 
Capture audience ideas for follow-on activities to engage technologists 

10:45 Closing Remarks Daniel O’Neil 

11:00 Adjourn 


Presenter / Moderator 
Elaine Gresham 
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